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? 
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

Back to the top