Meu Eclipse continua redefinindo as configurações do projeto para o pré-processador de C ++ incluindo provedores, especificamente o Analisador de Saída de Construção e o Compilador Interno. Eu tentei recriar o projeto, mas isso não ajuda. O projeto é do tipo "Projeto Makefile com código existente". Eu não estou fazendo nada de especial para ativá-lo - apenas escrevendo algum código.
Parece acontecer com mais frequência quando faço operações git, mas os arquivos / pastas .cproject, .project e .settings não estão no controle de origem - eles estão no meu arquivo de filtro gitignore e não foram adicionados. Veja o seguinte.
$ git ls-files -o -i --exclude-standard | grep -e project -e settings
.cproject
.project
.settings/language.settings.xml
Varia muito com que frequência isso acontece. Às vezes, são 5 a 10 minutos entre as redefinições, às vezes são horas.
A saída de estatísticas é um pouco interessante, depois que o Eclipse começou a reindexar as novas configurações. Como a data de leitura não foi atualizada, isso significa que o arquivo foi apenas escrito e nunca lido, ou seja, o Eclipse deve ter sido o único que o atualizou?
$ 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: -
Alguém já teve problemas semelhantes? Existe alguma maneira de solucionar problemas do Eclipse, vendo o que acha que acontece? Seu arquivo .log não é gravado quando o problema ocorre.
Versão do Eclipse: "Oxygen.3a Release (4.7.3a) ID do build: 20180405-1200"
Versão do CDT: "Ferramentas de desenvolvimento C / C ++ SDK 9.4.3.201802261533"
Sistema de arquivos: btrfs
SO: Ubuntu 16.04.5 LTS
O problema ocorreu porque o Eclipse CDT falhou ao iniciar o g ++ para obter as inclusões de pré-processador e as configurações do compilador. Ele falhou com o erro "falta de memória".
O que piorou o problema foi que meu computador não ficou sem memória. Ativar o overcommit usando sysctl -w vm.overcommit_memory=1 ajudou-me. Eu acho que o java forking com sua enorme alocação de memória assustou o kernel em pensar que precisaria de muito mais.