Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] How can I prevent the indexer taking over the entire CPU?
Sorry to interrupt your interaction with something potentially irrelevant, but I installed MARS on my old sid box the other week and saw this sort of behaviour. Totally unusable and infuriating. I thought it was something UI related, and wrote it off to being the fact it's sid with old libs, but you've got me thinking. I may have been experiencing two separate CPU hogging issues without realising it as my existing work space seemed to be one of the triggers (with CDT projects in it, among other things). I'll be following this.

On Tue, May 24, 2016 at 11:30 PM, Bossert, Andre <anb0s@xxxxxxxx> wrote:
Just created 100 snapshots and saw lot of isFileInternal() calls
BLOKCED or RUNNABLE:
...
"Worker-8" #46 prio=5 os_prio=0 tid=0x0000000020f77000 nid=0x1f34
runnable [0x000000002ad9e000]
   java.lang.Thread.State: RUNNABLE
at java.io.WinNTFileSystem.list(Native Method)
at java.io.File.list(Unknown Source)
at org.eclipse.cdt.internal.core.pdom.indexer.FileExistsCache.isFileInternal(FileExistsCache.java:114)
at org.eclipse.cdt.internal.core.pdom.indexer.FileExistsCache.isFile(FileExistsCache.java:67)
at org.eclipse.cdt.internal.core.pdom.indexer.ProjectIndexerInputAdapter.resolveIncludeFile(ProjectIndexerInputAdapter.java:114)
at org.eclipse.cdt.internal.core.index.IndexBasedFileContentProvider.isIncludedWithPragmaOnceSemantics(IndexBasedFileContentProvider.java:113)
at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor$1.checkFile(CPreprocessor.java:160)
at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor$1.checkFile(CPreprocessor.java:1)
...

We have compared our settings and it looks like the issues are related
to the setting C/C++ Indexer -> Allow heuristic resolution of
includes. We have disabled it and reimported the projects --> indexer
finishes in 10 Minutes and we saw no or short UI freezes... have to
investigate if all symbols etc. are still there and are right...

2016-05-24 13:00 GMT+02:00 Bossert, Andre <anb0s@xxxxxxxx>:
> Just attached some more dumps and see now that "Worker-8" where CDT is
> running has often BLOCKED state -> see dump "21" and later:
>
> e.g.
> ...
> "Worker-8" #46 prio=5 os_prio=0 tid=0x0000000020f77000 nid=0x1f34
> waiting for monitor entry [0x000000002ad9e000]
>    java.lang.Thread.State: BLOCKED (on object monitor)
> at java.lang.String.toUpperCase(Unknown Source)
> at java.lang.String.toUpperCase(Unknown Source)
> at org.eclipse.cdt.internal.core.pdom.indexer.FileExistsCache.isFileInternal(FileExistsCache.java:108)
> at org.eclipse.cdt.internal.core.pdom.indexer.FileExistsCache.isFile(FileExistsCache.java:67)
> at org.eclipse.cdt.internal.core.pdom.indexer.ProjectIndexerInputAdapter.resolveIncludeFile(ProjectIndexerInputAdapter.java:114)
> at org.eclipse.cdt.internal.core.index.IndexBasedFileContentProvider.isIncludedWithPragmaOnceSemantics(IndexBasedFileContentProvider.java:113)
> at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor$1.checkFile(CPreprocessor.java:160)
> at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor$1.checkFile(CPreprocessor.java:1)
> at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.findInclusion(CPreprocessor.java:1231)
> at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.executeInclude(CPreprocessor.java:1578)
> at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.executeDirective(CPreprocessor.java:1354)
> at org.eclipse.cdt.internal.core.parser.scanner.CPreprocessor.internalFetchToken(CPreprocessor.java:942)
> ...
>
> 2016-05-24 12:43 GMT+02:00 Bossert, Andre <anb0s@xxxxxxxx>:
>> Hello Doug,
>>
>> today i faced and analysed this issue with CDT indexer again. I've
>> attached some dumps created with jstack. How many are needed or what
>> are methods to look at?
>> Eclipse is now not responsive (ca. 20 Minutes) and is not refreshing
>> the GUI anymore, just sometimes i see an update, e.g. "C/C++ Indexer
>> (76%)" is the state now...
>>
>> Thanks and Regards,
>> Andre
>>
>> 2016-03-18 15:43 GMT+01:00 Doug Schaefer <cdtdoug@xxxxxxxxx>:
>>> jstack dumps periodically would be the best way to do it. We need to know
>>> where in the indexer it's stuck so look for org.eclipse.cdt.core type
>>> classes in the stacks, especially if they show up time after time. If you
>>> have a way to do some memory analysis, you could also see what objects are
>>> filling up memory.
>>>
>>> On Fri, Mar 18, 2016 at 5:20 AM, Bossert, Andre <anb0s@xxxxxxxx> wrote:
>>>>
>>>> We have similar issues at Windows 7 64bit with Luna and Mars releases,
>>>> but not with Kepler. During indexing all 4 or 8 cores are at 96% load
>>>> and Eclipse is not responsive or slow for 15-20 minutes sometimes. If
>>>> we file a bug request, what should be attached to the bug report? How
>>>> can we analyse it? Log files, dumps etc...
>>>>
>>>> 2016-03-17 14:51 GMT+01:00 Doug Schaefer <cdtdoug@xxxxxxxxx>:
>>>> > Sounds like a bug, please raise one. I used to see this when indexing
>>>> > boost.
>>>> > But I haven't tried lately.
>>>> >
>>>> > On Thu, Mar 17, 2016 at 9:22 AM, Steve Lorimer <steve.lorimer@xxxxxxxxx>
>>>> > wrote:
>>>> >>
>>>> >>
>>>> >> On 16 March 2016 at 15:09, Doug Schaefer <cdtdoug@xxxxxxxxx> wrote:
>>>> >>>
>>>> >>> You have parallel garbage collection happening and it's the 8 threads
>>>> >>> your talking about. Have you tried making your Xmx bigger? I'm
>>>> >>> guessing the
>>>> >>> indexer is causing you to run out of Java heap
>>>> >>
>>>> >>
>>>> >> Is there any way to prevent this from happening?
>>>> >>
>>>> >> What exactly is happening in the indexer that causes 8 GC threads to
>>>> >> spin
>>>> >> up to 100%?
>>>> >>
>>>> >> If I set -Xmx8G for the --launcher.appendVmargs section in eclipse.ini
>>>> >> does that mean I have 8GB heap? Why does the indexer blow through the
>>>> >> 8GB
>>>> >> heap?
>>>> >>
>>>> >> Can anyone suggest any way to prevent this from happening?
>>>> >>
>>>> >> Thanks in advance
>>>> >> Steve
>>>> >>
>>>> >> _______________________________________________
>>>> >> cdt-dev mailing list
>>>> >> cdt-dev@xxxxxxxxxxx
>>>> >> To change your delivery options, retrieve your password, or unsubscribe
>>>> >> from this list, visit
>>>> >> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > cdt-dev mailing list
>>>> > cdt-dev@xxxxxxxxxxx
>>>> > To change your delivery options, retrieve your password, or unsubscribe
>>>> > from
>>>> > this list, visit
>>>> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>>
>>>>
>>>>
>>>> --
>>>> Regards
>>>> Andre (anb0s)
>>>> eMail: anb0s@xxxxxxxx
>>>> _______________________________________________
>>>> cdt-dev mailing list
>>>> cdt-dev@xxxxxxxxxxx
>>>> To change your delivery options, retrieve your password, or unsubscribe
>>>> from this list, visit
>>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@xxxxxxxxxxx
>>> To change your delivery options, retrieve your password, or unsubscribe from
>>> this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
>>
>> --
>> Regards
>> Andre (anb0s)
>> eMail: anb0s@xxxxxxxx
>
>
>
> --
> Regards
> Andre (anb0s)
> eMail: anb0s@xxxxxxxx



--
Regards
Andre (anb0s)
eMail: anb0s@xxxxxxxx
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/cdt-dev

Back to the top