Bug 187000 - Debugger looses selection/focus a lot on the thread stack where you debug.
Summary: Debugger looses selection/focus a lot on the thread stack where you debug.
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P2 normal (vote)
Target Milestone: 3.3 RC2   Edit
Assignee: Darin Wright CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-15 09:21 EDT by Johan Compagner CLA
Modified: 2007-05-24 20:32 EDT (History)
0 users

See Also:
Michael_Rennie: review+
curtis.windatt.public: review+


Attachments
patch (9.07 KB, patch)
2007-05-18 16:45 EDT, Darin Wright CLA
no flags Details | Diff
updated patch (9.44 KB, patch)
2007-05-23 15:09 EDT, Darin Wright CLA
no flags Details | Diff
updated javadoc and length check on array to avoid index out of bounds (10.42 KB, patch)
2007-05-24 13:05 EDT, Darin Wright CLA
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Johan Compagner CLA 2007-05-15 09:21:00 EDT
Build ID:  I20070503-1400

Steps To Reproduce:
Just start debugging and press with the mouse the step over constantly. In my enviroment windows xp java 6 (and i have seen it now also on a co workers linux machine) many times the debugger looses the selection/focus on a stacktrace. Even the complete tree is collapsed and i really have to search for what thread is in suspend so that i can select it press step over once and then the tree expands again.

I always had some problems with this in older releases. But currently it is really bad it pretty much happens multiply times when i debug. 

The selection and focus should just stick as much as possible because if it looses focus i can't press step over. I have to wait and select the right thread again before i can go on.


More information:
Comment 1 Curtis Windatt CLA 2007-05-15 09:39:38 EDT
I expected this to be a duplicate of bug 177910 or bug 183504, but the fixes for those bugs were in before May 3rd. Needs investigation.
Comment 2 Johan Compagner CLA 2007-05-15 09:49:02 EDT
both of these bugs really decribe what i am seeing (and my co worker i just discussed it with hem again and he has the same thing on linux) 

As i said i had issues with this for a long time. But with the latest releases it is really much more appearing especially the total collapse of the thread tree stack. So that i really have to search for it which thread it was again. That i didn't really see a few builds ago (pre m5 if i had to guess)

My coworker doesn't really use the mouse to do step over, he the keyboard (F8) and is seeing the same thing.
Comment 3 Curtis Windatt CLA 2007-05-15 09:55:34 EDT
Can you turn on 'Show System Threads', in the debug view drop down menu and see if the behaviour continues?
Comment 4 Johan Compagner CLA 2007-05-15 10:07:23 EDT
i already had that enabled 
i will disabled it and see what happens then.
Comment 5 Curtis Windatt CLA 2007-05-15 14:40:43 EDT
What kind of program are you debugging, are there multiple threads? are several threads suspended at breakpoints? do you have a variable selected in the variables view?

Trying to come up with a decent test case.  Just stepping over when debugging eclipse is not causing any problems for me, but holding it down will eventually mess up the content of the debug view (selection lost, blank lines).
Comment 6 Johan Compagner CLA 2007-05-16 02:51:20 EDT
Most of the time it is just one thread that is suspended, i do have multiply threads in the the view because most of the time i am debugging a webserver (not remote but locally). But it could also be a swing app and then i am in the AWT event thread most of the time but then you also have multiply thread (a thread pool) but most are not touched.

i could have a variable selected but i don't think that is the case always (it happens to much for that) For me (and my co worker) it is really just stepping over or when it hits a breakpoint it doesn't collapse and select the right line (the stack tree is still in a collapse state)

i will try to figure it out when it really does happen for me, are you using the same build as me to test? or should i upgrade to another one?
Comment 7 Darin Wright CLA 2007-05-16 08:54:05 EDT
Do you have any logical structures being displayed when this happens?
Comment 8 Johan Compagner CLA 2007-05-16 09:08:56 EDT
I am testing it right now and i don't touch the variables view at all, i try to keep everything collapse there so it will only show the this and the params of the method. And it also happens when there are no params and the this is not a logical structure itself.

It does happen, especially the complete collapse of the thread stack, a lot when you step in and step out again of a method. So it has to set the variables view then yes to the next or previous stack.
And now you pointed me to the variables view i thought lets play with it. I closed the variables view completely from my debug perspective and started stepping. And yes no sudden focus lost anymore, no thread stacks collapse everything seem to work fine. Variables view again enabled and almost with the next step i do. collapse and focus lost..

Will try to see what is so special about my variables view then.
Comment 9 Johan Compagner CLA 2007-05-16 09:27:12 EDT
ok if i do have the variable view in the pespective but it isn't the selected tab everything goes fine. At the moment i click on the variable tab to show it within one or 2 steps focus is lost or the thread is collapsed.

I have disabled everything i can think of in the variables view:

Don't show logical structures
Don't show type names
Layout->Variables view only 
Java->Nothing selected


preferences: Java->Debug

I don't have detail formatters
Heap Walking: Display referenes not selected and both values 100
Logical structures: Default 4 and one of my own (but deleted that one and that didn't matter)
Primitive: Display Hex, Display ASCII are selected (but disabled all 3 that didn't matter)

Comment 10 Curtis Windatt CLA 2007-05-16 11:13:05 EDT
Tried to reproduce, same build, same settings.  By holding down the keys I can cause the views to go a little crazy, but eventually they catch up and the selection is correct.

Don't know what else is different in the setup.  Maybe it is related to what you are debugging.  Can you try a much simpler program, such as one that just loops over a println and then try stepping in/over?
Comment 11 Johan Compagner CLA 2007-05-16 11:25:33 EDT
the last test i did was pretty simple because it was a unitcase that i debugged

But maybe it is plugin i have installed or something like that but i don't know one that could really affect the debugging variables/debug view like that.

But i will test with a complete clean workspace and only eclipse plugins.
Comment 12 Johan Compagner CLA 2007-05-18 16:41:18 EDT
i tried pretty much everything

clean install of eclipse 3.3RC1:  I20070517-1700
with no adittional plugins.

I started eclipse with 1.5 and 1.6 and debugged simple apps with 1.5 and 1.6 but in all combinations i get the problem

The only thing i will try is also a clean/new repository 
which java versions are you testing on?
Comment 13 Darin Wright CLA 2007-05-18 16:43:53 EDT
I've been able to reproduce a scenario where the thread collapses when resuming
to a breakpoint iteratively (in LaunchConfiguration.exists()). I found that
closing the var view, or deselecting variables makes the problem go away. It
appears to be a problem where an implicit evaluation computing the toString()
for a variable is running when we compute the number of children for a thread
(which results in 0 children, since the thread is actually executing).
Comment 14 Darin Wright CLA 2007-05-18 16:45:30 EDT
Created attachment 67871 [details]
patch

Work in progress uses scheduling rules to ensure that an evaluation does not run at the same time as content jobs. However, this does not work for explicit evaluations that suspend at breakpoints (since we need to generate content in the midst of an evaluation in that case).
Comment 15 Johan Compagner CLA 2007-05-18 17:10:57 EDT
can somebody give me the classes (attach to this bug or send it to my email)
i don't have eclipse checked out and the patch doesn't work on the import as plugins/frage
Comment 16 Darin Wright CLA 2007-05-22 12:31:31 EDT
Marking as RC2 candidate
Comment 17 Darin Wright CLA 2007-05-23 15:09:13 EDT
Created attachment 68424 [details]
updated patch

This patch limits the serialization to implicit evaluations and content jobs (allows content jobs to run with explicit evaluations).
Comment 18 Johan Compagner CLA 2007-05-23 17:35:32 EDT
i would be happy to see if the patch works if i could have a patch file that works on the import plugin or fragements projects or if somebody pointed me to the binary jar file that i could drop over my current one.
Comment 19 Johan Compagner CLA 2007-05-24 11:53:55 EDT
thx darin for giving me the jars, i tested it quickly and the results are very very promissing! 

I have debugged a unit test what i normally do for testing this. And what ever i did step in step out step over. Never the focus got lost or the stack tree collapses on me.
Comment 20 Curtis Windatt CLA 2007-05-24 12:53:09 EDT
+1 Patch solves the problem.  By putting breakpoints during various parts of the viewer updates and slowing down the detail formatters/toString() I can make some strange things happen.  However, doing the same things without the patch also results in strange viewer states.  The patch isn't adding to those problems.

Johan, please let us know if you see any strange behaviour.
Comment 21 Darin Wright CLA 2007-05-24 13:05:50 EDT
Created attachment 68614 [details]
updated javadoc and length check on array to avoid index out of bounds
Comment 22 Curtis Windatt CLA 2007-05-24 14:15:19 EDT
Changes in the updated patch are good.  Still +1 from me.
Comment 23 Michael Rennie CLA 2007-05-24 15:51:42 EDT
works good on windows and Linux +1, applied patch.
Comment 24 Michael Rennie CLA 2007-05-24 15:51:54 EDT
verified
Comment 25 Johan Compagner CLA 2007-05-24 17:38:28 EDT
i have tested it further and what ever i do, run to line, step into selection everything just works. The thread view always keeps the focus and i can always just press the next step button.. 
thx guys this is great, it was becomming pretty annoying :)

which build is it in? (i now don't want to go back! ;)
Comment 26 Darin Wright CLA 2007-05-24 20:32:58 EDT
The fix went into today's 1800 build. It will be in the offical RC2 release this week.