What do I do when the Eclipse CDT indexer gets stuck?

Question

I'm using Eclipse CDT 2020-06 (but this has happened to me with earlier versions.)

Sometimes, the Eclipse CDT gets stuck parsing some file. The percentage indicator doesn't advance; and pressing the task's cancel button makes it "Cancel Requested", but it stays stuck that way. So, not only can I then not use the index for my project, but most other "async" tasks queue up and don't get carried out, either. When this happens I now basically give up and restart; and perhaps end up masking out the misbehaving file with a filter rule.

My question is: Is there something better I can do to handle the indexer getting stuck?

edit:

If I run Eclipse with -debug and enable indexer debugging, the only output I get is:

Indexer: start PDOMFastIndexerTask
Indexer: parsing /cuda-api-wrappers/examples/other/io_compute_overlap_with_streams.cu

and that's where I get stuck.

Answer 1

How to "unstick" Eclipse's indexer

I've been using Eclipse professionally now on Linux (for code editing only, NOT building--which I do at the command-line) for 4 years, on massive mono-repos up to 200 GiB in code size. My indexer has gotten stuck hundreds of times, and these 2 solutions seem to pretty consistently work to "unstick" the indexer.

1. Increase the heap (RAM) available to Eclipse

Doubling my max RAM available to Eclipse from 8 GiB to 16 GiB fixed it for me. It was stuck for hours at 4841/7617 sources, 27463 headers, parsing the same file forever, with the RAM maxed out at 8 GiB. Once I updated the RAM (heap) available to Eclipse from 8 to 16 GiB, I let the indexer run overnight for 10 hrs and by the morning it was finished.

Note: if trying to index the Boost libraries, some initial testing leads me to suspect it'll take Eclipse somewhere around a whopping 64 GiB~128 GiB of RAM (heap) to index them, so I usually just exclude all or most of the Boost libraries from indexing as a general rule.

To double the RAM available to Eclipse, open (on Linux): /home/username/eclipse/embedcpp-2021-06/eclipse/eclipse.ini, or the equivalent path for you, and modify the -Xmx value. Ex: I increased mine from -Xmx8196m (8196 MiB, or 8 GiB) to -Xmx16384m (16384 MiB, or 16 GiB). Close and re-open Eclipse for this change to take effect.

Also, turn on showing the heap status at the bottom of the Eclipse window (if it isn’t already on by default):

Window → Preferences → General → check the box for “Show heap status” → click “Apply and Close”. Here’s what it looks like now at the bottom of the Eclipse window!

Source:

1. My Google document above, p12.
2. See also: How to view memory usage in eclipse (beginner)

You may need to give your PC more virtual memory to support the above RAM increase

If you don't have enough physical RAM to handle this increase, but you have a high-speed SSD, you can use your SSD as virtual memory to make up for not enough physical memory. This can be done on both Windows and Linux, and probably Mac too. If on Linux, follow my instructions here to increase your vitual memory swapfile to something more usable: ex: increase it to 32 GiB. Now, the max heap size you can set your Eclipse to use will be equal to physical memory (real RAM) + virtual memory swapfile (fake "RAM" emulated on your solid state drive). Leave a few GiB for other programs though--don't give it all to Eclipse.

2. Exclude all build folders and 3rd-party libraries (especially Boost!) which you do not need to index

See my very-detailed answer on how to do this using 1) Resource Filters, and 2) a manual symlink-generator script (my preferred choice) here: How to exclude all parts of a folder in Eclipse except for a few specific sub-folders within it

Going further

I write about this and a ton of other settings and things you might find useful in my Eclipse setup document you can find here:

1. https://github.com/ElectricRCAircraftGuy/eRCaGuy_dotfiles/tree/master/eclipse.
2. Direct link to the Google doc

See also: What's the recommended Eclipse CDT configuration for big C++ project (indexer takes forever)

Answer 2

In my case I had to go to .metadata/.plugins/org.eclipse.cdt.core and delete the *.pdom files for my project.

Indexer was stuck at 0%, nothing else worked, including restarting eclipse, closing the project, refresh all, rebuild index, deleting the source files were it was stuck, etc.

Answer 3

Is there something better I can do to handle the indexer getting stuck?

You can try to debug Eclipse indexer yourself. Run Eclipse from console with -debug option:

eclipse -debug <options file>'

where <options file> contents is:

org.eclipse.cdt.core/debug=true
org.eclipse.cdt.core/debug/indexer/activity=true
org.eclipse.cdt.core/debug/indexer/statistics=true
org.eclipse.cdt.core/debug/indexer/problems=true

Look at debug output when indexer is stuck. You will probably see some error messages from indexer which can be googled further.

Answer 4

I have reason to believe this may have something to do with NVIDIA's Eclipse plugins for CUDA support. The indexer gets stuck on .cu files; and with a new version of Eclipse and without the plugins, indexing concludes without a hitch.