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

Back to the top