0

My Eclipse keeps resetting the project settings for the C++ preprocessor includes providers, specifically the Build Output Parser and the Built-in Compiler. I've tried recreating the project, but it doesn't help. The project is of type "Makefile project with existing code". I'm not doing anything special to trigger it - just writing some code.

It seems to happen more often when I do git operations, but the .cproject, .project, and .settings files/folders are not in source control - they are in my gitignore filter file and not added. See the following.

$ git ls-files -o -i --exclude-standard  | grep -e project -e settings
.cproject
.project
.settings/language.settings.xml

It varies a lot how often it happens. Sometimes it's 5-10 minutes between resets, sometimes it's hours.

Stat output is a bit interesting, after Eclipse has started reindexing with the new settings. As the read date has not been updated, does it mean that the file has only been written and never read, i.e. Eclipse must have been the one updating it?

$ stat .settings/language.settings.xml 
  File: 'language.settings.xml'
  Size: 1176        Blocks: 8          IO Block: 4096   regular file
Device: 2dh/45d Inode: 62805379    Links: 1
Access: (0664/-rw-rw-r--)  Uid: ( 1000/  raahlb)   Gid: ( 1000/  raahlb)
Access: 2018-09-03 17:28:32.679448329 +0200
Modify: 2018-09-03 17:47:32.200812926 +0200
Change: 2018-09-03 17:47:32.200812926 +0200
 Birth: -

Has anyone had similar problems? Is there some way to troubleshoot Eclipse, seeing what it thinks happens? Its .log file is not written to when the problem occurs.

Eclipse version: "Oxygen.3a Release (4.7.3a) Build id: 20180405-1200"
CDT version: "C/C++ Development Tools SDK 9.4.3.201802261533"
Filesystem: btrfs
OS: Ubuntu 16.04.5 LTS

0

The problem was due to Eclipse CDT failing to launch g++ for getting the pre-processor includes and compiler settings. It failed with the "out of memory" error.

What made the problem worse was that my computer actually didn't run out of memory. Enabling overcommit using sysctl -w vm.overcommit_memory=1 helped for me. I think java forking with its huge allocation of memory scared the kernel into thinking it would need as much again.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.