Community
Participate
Working Groups
We are an adopting product, and we have a test scenario that sometimes goes into an infinite loop. The loop appears to be in one of these methods:: at org/eclipse/core/internal/jobs/JobManager.findBlockingJob(Bytecode PC:92(Compiled Code)) at org/eclipse/core/internal/jobs/JobManager.doRunNow(Bytecode PC:2(Compiled Code)) Here is a snapshot of the "hot" thread: Worker-3 stack: "Worker-3" J9VMThread:0x4611D100, j9thread_t:0x45A007FC, java/lang/Thread:0x0318E6B8, state:CW, prio=5 (native thread ID:0xB4C, native priority:0x5, native policy:UNKNOWN) Java callstack: at org/eclipse/core/runtime/Path.isPrefixOf(Bytecode PC:105(Compiled Code)) at org/eclipse/core/internal/resources/Resource.isConflicting(Bytecode PC:105(Compiled Code)) at org/eclipse/core/runtime/jobs/MultiRule.isConflicting(Bytecode PC:92(Compiled Code)) at org/eclipse/core/internal/jobs/InternalJob.isConflicting(Bytecode PC:92(Compiled Code)) at org/eclipse/core/internal/jobs/JobManager.findBlockingJob(Bytecode PC:92(Compiled Code)) at org/eclipse/core/internal/jobs/JobManager.doRunNow(Bytecode PC:2(Compiled Code)) at org/eclipse/core/internal/jobs/JobManager.runNow(Bytecode PC:2(Compiled Code)) at org/eclipse/core/internal/jobs/ThreadJob.waitForRun(Bytecode PC:77(Compiled Code)) at org/eclipse/core/internal/jobs/ThreadJob.joinRun(Bytecode PC:68) at org/eclipse/core/internal/jobs/ImplicitJobs.begin(Bytecode PC:208(Compiled Code)) at org/eclipse/core/internal/jobs/JobManager.beginRule(Bytecode PC:16(Compiled Code)) at org/eclipse/ui/internal/ide/ContentTypeDecorator.decorate(Bytecode PC:16(Compiled Code)) at org/eclipse/ui/internal/decorators/LightweightDecoratorDefinition.decorate(Bytecode PC:85(Compiled Code)) at org/eclipse/ui/internal/decorators/LightweightDecoratorManager$LightweightRunnable.run(Bytecode PC:12(Compiled Code)) at org/eclipse/core/runtime/SafeRunner.run(Bytecode PC:7(Compiled Code)) at org/eclipse/ui/internal/decorators/LightweightDecoratorManager.decorate(Bytecode PC:14(Compiled Code)) at org/eclipse/ui/internal/decorators/LightweightDecoratorManager.getDecorations(Bytecode PC:14(Compiled Code)) at org/eclipse/ui/internal/decorators/DecorationScheduler$1.ensureResultCached(Bytecode PC:87(Compiled Code)) at org/eclipse/ui/internal/decorators/DecorationScheduler$1.run(Bytecode PC:146) at org/eclipse/core/internal/jobs/Worker.run(Bytecode PC:31(Compiled Code))
Created attachment 186393 [details] Yourkit snapshot This is a Yourkit snapshot, that was taken during the loop. I'm unsure of the exact Eclipse driver, but the driver would have been a little earlier than 2010/12/10.
We also have full crash dump (from which you can see call of the values in the heap), which I can send, if it would be helpful.
I have a suspicion this is related to bug 320329. In that bug, there is a situation in which ThreadJob#waitForRun enters into a busy wait loop with no sleeping. This condition is very CPU intensive and would have execution stacks looking like the one attached here. The only difference here is the "infinite" part... In bug 320329 there is no infinite loop, just a busy-wait loop that will eventually complete. So, can you confirm that in your case the loop never exits? How long did you wait for it? If you can still reproduce, it would also be worth trying another run with the fix for bug 320329 to see if the problem is the same.
I havent been able to reproduce this loop in any of the test scenarios that previously produced it. I suggest closing this for now, and if it reappears then we can re-open and investigate further.
(In reply to comment #4) > I havent been able to reproduce this loop in any of the test scenarios that > previously produced it. I suggest closing this for now, and if it reappears > then we can re-open and investigate further. Ok.
