Bug 75646

Summary: Endless loop? in DefaultCommentMapper.storeLeadingComments
Product: [Eclipse Project] JDT Reporter: Michael Valenta <Michael.Valenta>
Component: CoreAssignee: Frederic Fusier <frederic_fusier>
Status: RESOLVED DUPLICATE QA Contact:
Severity: critical    
Priority: P3 CC: daniel_megert, markus.kell.r
Version: 3.0   
Target Milestone: 3.1 M3   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
VM dump none

Description Michael Valenta CLA 2004-10-05 10:46:36 EDT 
I am running on todays integration build and it is bordering on unusable due 
to 3-5 second delays that happen frequently. On taking a VM snapshot, one of 
the things I noticed was a large number of SelectionListenerWithASTManager 
jobs. Should there really be that many of these jobs? I have the entire 
Eclipse base a s source which may be a trigger. Marking as major due to the 
response times I am seeing (although this may or may not be the cause of 
that). I will attach the VM trace.
Comment 1 Michael Valenta CLA 2004-10-05 10:47:43 EDT 
Created attachment 15006 [details]
VM dump
Comment 2 Michael Valenta CLA 2004-10-05 11:56:24 EDT 
Changing to critical. The build is unusable for me.
Comment 3 Dani Megert CLA 2004-10-06 08:28:22 EDT 
*** Bug 75651 has been marked as a duplicate of this bug. ***
Comment 4 Dani Megert CLA 2004-10-06 11:53:42 EDT 
I just run into this as well (editing ASTProvider.java), the CPU stays at 100%
and the stack trace is always at the same place (while creating an AST). Endless
loop?
org/eclipse/jdt/core/dom/DefaultCommentMapper.storeLeadingComments(DefaultCommentMapper.java:321)



This bug uncovered some other minor issues that need to be improved:
- instead of n waiting SelectionListenerWithASTManager jobs of which n-1 will be
cancelled immediately when invoked only create one waiting job (filed bug 75710)
- if the SelectionListenerWithASTManager waits for an AST and the editor closes
we should not create an AST for that one but return null (filed bug 75711)
Comment 5 Michael Valenta CLA 2004-10-06 11:59:03 EDT 
Is there some way to disable this background job? I am still trying to use 
yesterdays build but too many operations are adversly affected. For example, 
performing an Open Types (CTRL-SHIFT-T) shows a progress dialog for an 
extremely long time before opening the types dialog. Others don't seem to have 
the same issue so I'm wondering if they have some preference configuration 
that bypasses this problem.
Comment 6 Dani Megert CLA 2004-10-06 13:08:06 EDT 
Nothing you can do: the AST gets created during reconcile and this is
synchronized with the compilation unit. Every operation that synchronizes on
that same CU has to wait.
Comment 7 Frederic Fusier CLA 2004-10-06 15:51:23 EDT 

*** This bug has been marked as a duplicate of 75632 ***