Skip to content

Critical memory leak #962

Open
Open

Description

@HyperWinX

Observed behavior

I detected critical memory leak in CCLS. I use Arch Linux on linux-zen 6.8.8 kernel. CPU - AMD FX-8350, 16GB RAM. I compiled clang-git from AUR with enabled -fsanitize=address to get report when it crashes. Yes, every save (probably) CCLS run 2-4 more jobs without ending others, so after some time i get over 200 jobs on small project, containing several hundreds of lines of code. In this time CCLS uses 1.5GB of RAM and 30TB of virtual RAM. Then it crashes with following reports:

=================================================================
==21974==ERROR: AddressSanitizer: requested allocation size 0x7e750f672170 (0x7e750f673170 after adjustments for alignment, red zones etc.) exceeds maximum supported size of 0x10000000000 (thread T5)
    #0 0x5d678ae3dd89 in malloc (/usr/bin/ccls+0x126d89) (BuildId: 26bd40cd47bdaebbefcf51c149c7159af78c7241)
    #1 0x7e750fedec48 in llvm::SmallVectorBase<unsigned long>::grow_pod(void*, unsigned long, unsigned long) (/usr/lib/libLLVM-17.so+0x6dec48) (BuildId: 23cd725c53bbcb975bb284794c263d7ee44cbd7f)

==21974==HINT: if you don't care about these errors you may set allocator_may_return_null=1
SUMMARY: AddressSanitizer: allocation-size-too-big (/usr/bin/ccls+0x126d89) (BuildId: 26bd40cd47bdaebbefcf51c149c7159af78c7241) in malloc
Thread T5 created by T0 here:
    #0 0x5d678ae34fa8 in pthread_create (/usr/bin/ccls+0x11dfa8) (BuildId: 26bd40cd47bdaebbefcf51c149c7159af78c7241)
    #1 0x5d678af8ac5c in ccls::spawnThread(void* (*)(void*), void*) /usr/src/debug/ccls-git/ccls/src/platform_posix.cc:75:3
    #2 0x5d678affa7bd in ccls::SemaManager::SemaManager(ccls::Project*, ccls::WorkingFiles*, std::function<void (std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char>>, std::vector<ccls::Diagnostic, std::allocator<ccls::Diagnostic>>)>, std::function<void (ccls::RequestId)>) /usr/src/debug/ccls-git/ccls/src/sema_manager.cc:762:3
    #3 0x5d678af70ea1 in ccls::pipeline::mainLoop() /usr/src/debug/ccls-git/ccls/src/pipeline.cc:625:15
    #4 0x5d678aea3610 in main /usr/src/debug/ccls-git/ccls/src/main.cc:146:7
    #5 0x7e750f241ccf  (/usr/lib/libc.so.6+0x25ccf) (BuildId: 6542915cee3354fbcf2b3ac5542201faec43b5c9)

==21974==ABORTING
ccls server connection was closed
[Error - 7:06:19 PM] Connection to server got closed. Server will not be restarted.
[Error - 7:06:19 PM] Request textDocument/completion failed.
Error: Connection got disposed.
	at Object.dispose (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/main.js:904:25)
	at Object.dispose (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-languageclient/lib/client.js:74:35)
	at LanguageClient.handleConnectionClosed (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-languageclient/lib/client.js:2309:42)
	at LanguageClient.handleConnectionClosed (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-languageclient/lib/main.js:155:15)
	at closeHandler (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-languageclient/lib/client.js:2296:18)
	at CallbackList.invoke (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/events.js:62:39)
	at Emitter.fire (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/events.js:121:36)
	at closeHandler (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/main.js:240:26)
	at CallbackList.invoke (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/events.js:62:39)
	at Emitter.fire (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/events.js:121:36)
	at StreamMessageWriter.fireClose (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/messageWriter.js:39:27)
	at Socket.<anonymous> (/home/hyperwin/.vscode-oss/extensions/ccls-project.ccls-0.1.29-universal/node_modules/vscode-jsonrpc/lib/messageWriter.js:58:46)
	at Socket.emit (node:events:517:28)
	at Pipe.<anonymous> (node:net:350:12)

compile_commands.json:

[
{
  "directory": "/home/hyperwin/d/Projects/HSharpVE_Engine/build/src",
  "command": "/usr/bin/c++  -I/home/hyperwin/d/Projects/HSharpVE_Engine/include -std=gnu++23 -Wall -Werror -O0 -ggdb3 -o CMakeFiles/hve_ng.dir/main/file.cpp.o -c /home/hyperwin/d/Projects/HSharpVE_Engine/src/main/file.cpp",
  "file": "/home/hyperwin/d/Projects/HSharpVE_Engine/src/main/file.cpp",
  "output": "src/CMakeFiles/hve_ng.dir/main/file.cpp.o"
},
{
  "directory": "/home/hyperwin/d/Projects/HSharpVE_Engine/build/src",
  "command": "/usr/bin/c++  -I/home/hyperwin/d/Projects/HSharpVE_Engine/include -std=gnu++23 -Wall -Werror -O0 -ggdb3 -o CMakeFiles/hve_ng.dir/main/main.cpp.o -c /home/hyperwin/d/Projects/HSharpVE_Engine/src/main/main.cpp",
  "file": "/home/hyperwin/d/Projects/HSharpVE_Engine/src/main/main.cpp",
  "output": "src/CMakeFiles/hve_ng.dir/main/main.cpp.o"
},
{
  "directory": "/home/hyperwin/d/Projects/HSharpVE_Engine/build/src",
  "command": "/usr/bin/c++  -I/home/hyperwin/d/Projects/HSharpVE_Engine/include -std=gnu++23 -Wall -Werror -O0 -ggdb3 -o CMakeFiles/hve_ng.dir/parser/tokenizer.cpp.o -c /home/hyperwin/d/Projects/HSharpVE_Engine/src/parser/tokenizer.cpp",
  "file": "/home/hyperwin/d/Projects/HSharpVE_Engine/src/parser/tokenizer.cpp",
  "output": "src/CMakeFiles/hve_ng.dir/parser/tokenizer.cpp.o"
}
]

Expected behavior

It supposed to be stable, isnt it?

Steps to reproduce

  1. Open any CMake based project in VSC (VS Code or VSCodium).
  2. Ofc you should have compile_commands.json in root of project.
  3. Work on project, and spectate how jobs count is raising.
  4. After some time you will get status "ccls: error" in the tray and error log in terminal, reporting about not enough memory.

System information

CCLS:

ccls version 0.20240202-0-gf8d2778b

CLang:

clang version 17.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
Found CUDA installation: /opt/cuda, version

OS:

Arch Linux, 6.8.8 linux-zen kernel

Editor:

VSCodium 1.88.1

CCLS extension version v0.1.29

Activity

  1. niumeng07 commented on Aug 2, 2024

    @niumeng07

    MacOS, same memory leak

  2. DesktopFolder commented on Sep 16, 2024

    @DesktopFolder

    Pretty sure I have also had this issue, MacOS (M2 Sonoma + NeoVim), operating system fully crashed while editing pretty basic files with CCLS taking up extreme system resources (could not get memory diagnostics).

  3. HyperWinX commented on Sep 16, 2024

    @HyperWinX
    Author

    Looks like ccls is dead. Use clangd guys

  4. DesktopFolder commented on Sep 16, 2024

    @DesktopFolder

    CCLS only has one developer, & clangd has its own issues; I'll just stick with restarting my editor every once in a while for now as a workaround.

  5. HyperWinX commented on Sep 16, 2024

    @HyperWinX
    Author

    What issues clangd has? Never noticed any, works absolutely fine, and no need to restart editor. CCLS gets really annoying in long coding sessions, like, 10 hours or more

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions