LLVM ERROR: out of memory #320
Comments
|
As you see ( This is not necessarily a llvm/clang/ccls problem. If your project is large, higher memory consumption is expected. The peak memory usage happens when ccls is indexing your project with You can also change the initialization option |
my pc is "AMD 2950X 32G " |
|
I'm curious about msvc's performance on your project |
|
I think ccls should be smarter about how it chooses the number of threads to use. I have this same issue in #316 , except I don't get a nice "Out of memory" error, ccls goes into uninterruptible sleep state. ccls currently uses std::hardware_concurrency threads() to determine number of threads, but it could be smarter and look at how much memory is available in the system to be smart about limiting the number of threads in case using std::hardware_concurrency threads() would exhaust the memory. |
|
@rbresalier #316 (comment) You passed it wrong :(
This is as difficult as determining the best |
I disagree. It is bad because users get either "Out of memory" error or uinterruptible sleep with the default behavior. In my machine with 72 threads, default ccls behavior will always cause uninterruptible sleep. I don't think it is ever acceptable for any program to crash like this. The default behavior doesn't have to be perfect. Yes it is difficult to determine the very best number of threads to use - but I think the default behavior should strive to make a balance between the best choice and not crashing. If a user really wants to achieve better than the default then they can play with the number of threads. I truly believe the default should not cause crashes with no hint of what the problem is. |
|
I also think the ccls algorithms are using too much memory. With the same code base, but using cquery instead, I observe cquery using up to 113 indexer threads and using 5.28GByte in my system. My system has 256GByte and 72 cores. So why does ccls run out of memory, 256GByte with 72 threads while cquery can live with 5.28GByte and 113 indexer threads? |
There could be other issues we haven't diagnosed. The filesystem can have problems. Clang may take significantly more memory parsing some code patterns. Check your cgroup
They should tune the
I disagree that uninterruptible sleep was ccls's fault.
Really appreciated if you can give some numbers about how much saving it makes by changing it to 0. Don't get me wrong. I take memory usage seriously. If you read my old commits in cquery, you shall notice changes like: changing const double grow = 1.3;
size_t t;
if ((t = funcs.size() + u->funcs_hint) > funcs.capacity()) {
t = size_t(t * grow);
funcs.reserve(t);
func_usr.reserve(t);
}If you are really motivated, try some older versions (especially those releases before last October; some fields had to be added for new features).
index::IndexingOptions IndexOpts;
IndexOpts.SystemSymbolFilter =
index::IndexingOptions::SystemSymbolFilterKind::All;
IndexOpts.IndexFunctionLocals = true;
IndexOpts.IndexImplicitInstantiation = true;
#if LLVM_VERSION_MAJOR >= 9
IndexOpts.IndexParametersInDeclarations = true;
IndexOpts.IndexTemplateParameters = true;
#endif |
I agree and I think one of these issues should be reopened. With same code base, cquery does not have uninterruptible sleep with 113 threads, yet ccls does with default settings (72 threads on my system). Reducing threads in ccls makes the issue go away, but since cquery can spawn 113 threads, ccls should be able to spawn 72 threads on my system. Maybe you can try to recreate the issue on your system by telling ccls to spawn 72 threads (even though you have less CPU cores) and see what happens? And then you can try to get cquery to spawn 113 threads like I have in my system.
This is not about assigning fault. Most applications perform validation on user's input that would break the application and let user know. For example, if application asks me a question to answer yes/no, and I answer "maybe", application will tell me I made an error. Similarly if user asks ccls for too many threads that could cause a crash, it would be much more user friendly to let the user know instead of allowing the user's input to crash the system with no clue as to how to fix it. As a new user to ccls, my first experience as uninterruptible sleep and I had no idea why - I know nothing about number of threads. It would be nice to know why.
But how would a user even know to do this? I was a new user of ccls, I knew nothing about it. I tried it with its default settings and it went into uninterruptible sleep. To find out that I had to change # of threads, I had to raise an issue on github and have lots of discussion. If ccls just told me about a potential issue I would have saved so much time. Would be much more user friendly to tell or warn the user instead of just crashing and the user, who knows nothing about ccls, has no clue why. It is not about assigning fault. Anyway, this is probably a moot issue because I think there is an un-diagnosed problem and ccls should work with 72 threads on my system, just because cquery works with 113 threads. If that issue is solved, I wouldn't need to reduce the number of threads. |
|
I tried retainInMemory: 0. Very quickly after I open gVim I see error in gVim: "Language server cpp exited unexpectedly: failed to fill the whole buffer" and ccls is dead. With retainInMemory:1, I get uinterruptible sleep state. I had to move to latest release, 0.20190308.1, in order to get the retainInMemory option, it was not available in the 0.20181225.8 release I was using earlier. |
|
Again, I don't think the #316 OOM is a ccls issue. Answered in #316 (comment) but replied here for one question
There might be some versions using |
|
The commit "Add initialization option index.initialNoLinkage: false" should decrease memory usage a lot. |
|
Same problem. I use Arch Linux machine based on FX-8350 and 16GB of RAM. I added "-fsanitize=address" to CFLAGS/CXXFLAGS variables in /etc/makepkg.conf, and compiled ccls-git AUR package. When i work in VSC, every save (probably) CCLS runs several more jobs. After some time i have 200-250 jobs already. Project has several hundreds of lines of code, but CCLS uses 1.5GB of RAM and 30TB of virtual memory. Then it crashed, and i got report of CCLS and AddressSanitizer. Yes, 2024, and this bug is still present |
I don't think this is a ccls bug. If you build ccls with |
It's been all right before. After updating LLVM and CLLS, that's it.
The text was updated successfully, but these errors were encountered: