Community
Participate
Working Groups
When the debugger stops at a breakpoint it sometimes loses focus when a new thread is created and destroyed out of the debug scope. The result is that you cannot continue debugging until you manually select your thread from the debug view. This is a regression from eclipse version 3.2.
Agree that this is a regression, but given that there is a trivial workaround, I'm reducing the severity.
I think this may be a dup of bug 212798, which has been fixed in 3.5. Without a test case it's hard to tell. Propose to close.
Getting similar behavior (stack trace loses focus) during debug. This is during remote debug of web app, I can see threads constantly being created/terminated. Running on 3.6 RC2.
(In reply to comment #3) > Getting similar behavior (stack trace loses focus) during debug. > This is during remote debug of web app, I can see threads constantly being > created/terminated. > Running on 3.6 RC2. When this happens, does the active thread (the thread you were on) remain expanded? Or does it collapse? If you can reproduce this consistently, can you gather a trace using the following trace options: org.eclipse.debug.ui/debug = true org.eclipse.debug.ui/debug/viewers/deltas = true org.eclipse.debug.ui/debug/viewers/contentProvider = true org.eclipse.debug.ui/debug/viewers/presentationId = org.eclipse.debug.ui.DebugView
When I have seen this problem, the active thread totally disappears and I do not have any context -it seems to appear and re-appear at the bottom of the list, intermittently.
The selection policy in the debug view is designed to select threads as they suspend, unless the user currently has a suspended frame selected. However, when a thread is in the middle of a step (i.e. step started but not yet complete), the top frame is not considered to be suspended. So, if another thread suspends before a step completes, it will be selected. I wonder if this might be causing problems. (It can be a feature when the user wants to step from one thread to another as locks/monitors are obtained/released, but it might also be causing havock).
Created attachment 172151 [details] log info (In reply to comment #4) > (In reply to comment #3) > > Getting similar behavior (stack trace loses focus) during debug. > > This is during remote debug of web app, I can see threads constantly being > > created/terminated. > > Running on 3.6 RC2. > > When this happens, does the active thread (the thread you were on) remain > expanded? Or does it collapse? > > If you can reproduce this consistently, can you gather a trace using the > following trace options: > > org.eclipse.debug.ui/debug = true > org.eclipse.debug.ui/debug/viewers/deltas = true > org.eclipse.debug.ui/debug/viewers/contentProvider = true > org.eclipse.debug.ui/debug/viewers/presentationId = > org.eclipse.debug.ui.DebugView When this happens the active thread is collapsed. Attached (log.txt) is the log info from three occasions I was able to reproduce.
Also experiencing this on a Mac, with remote debugging of a larger webapplication with many threads. Around 2-5 seconds after focus on a breakpoint, the focus jumps back to the root of the debug thread tree, and makes debugging impossible, since there is no time to look at the variables etc. Versions tested: - Galileo (JDT version 3.5.2.r352) with Cocoa 64-bit libs - Helios 3.6 RC 4 with Cocoa 64-bit SWT - Helios 3.6 RC 4 with Cocoa 32-bit SWT - (couldn't test 3.6 RC 4 with carbon, it crashed on startup) Always under Mac OS X 10.6, with Java 1.6.0. (In reply to comment #1) > Agree that this is a regression, but given that there is a trivial workaround, What is the trivial workaround?
Answering myself: doesn't happen for me if I configure the debug tree view and uncheck "Java -> Show thread groups" from the view drop down menu.
(In reply to comment #9) > Answering myself: doesn't happen for me if I configure the debug tree view > and uncheck "Java -> Show thread groups" from the view drop down menu. Thanks for the update. I was not testing/debugging with thread groups showing, so I was not aware this might be the problem. Are others using "thread groups"? I think the "workaround" was to re-select the thread of interest. However, if selectoin continuously changes, it's not optimal.
(In reply to comment #10) > (In reply to comment #9) > > Answering myself: doesn't happen for me if I configure the debug tree view > > and uncheck "Java -> Show thread groups" from the view drop down menu. > > Thanks for the update. I was not testing/debugging with thread groups showing, > so I was not aware this might be the problem. Are others using "thread groups"? > > I think the "workaround" was to re-select the thread of interest. However, if > selectoin continuously changes, it's not optimal. I didn't have the "show thread groups" checked when this happened, agree that the workaround is not optimal, in some cases it takes a few seconds for thread to lose focus, selecting it again is really not an option.
This is still happening in eclipse 3.6. Is there any more information needed? this is really making it hard to debug...
(In reply to comment #12) > This is still happening in eclipse 3.6. > Is there any more information needed? this is really making it hard to debug... More information or a screencast might be useful. When selection moves to another thread, is the thread that you are focused on completely suspended or are you also stepping in that thread?
(In reply to comment #13) > (In reply to comment #12) > > This is still happening in eclipse 3.6. > > Is there any more information needed? this is really making it hard to debug... > > More information or a screencast might be useful. When selection moves to > another thread, is the thread that you are focused on completely suspended or > are you also stepping in that thread? The thread in focus is completely suspended and expended (in the debug view), when focus is lost it becomes collapsed, and I need to expand and select the frame in order to continue debug.
(In reply to comment #14) > (In reply to comment #13) > > (In reply to comment #12) > > > This is still happening in eclipse 3.6. > > > Is there any more information needed? this is really making it hard to debug... > > > > More information or a screencast might be useful. When selection moves to > > another thread, is the thread that you are focused on completely suspended or > > are you also stepping in that thread? > > The thread in focus is completely suspended and expended (in the debug view), > when focus is lost it becomes collapsed, and I need to expand and select the > frame in order to continue debug. Attached two screencasts: 1) shows how during active debug the current suspended thread looses focus. http://goview.com/?id=dff2dc2e-1057-4a1e-87ad-6fca73c5c537 2) shows how the debug view keeps refreshing (title and scroll jumps) because of threads created/destroyed constantly. http://goview.com/?id=0b0a0d6d-65d4-4fe1-b255-7df8bb5e4930
This issue should be a P1, not a P3. It seems that I am spending too much time refinding my current thread to continue debugging. Then once I select my current thread and location, I go to step through the code. Before I click step over or step into, another thread has been created or destroyed and I get to do the process all over again. Needless to say this bug has made debugging more of a chore. I have JDT 1.02 installed on Eclipse 3.4.
Is there an ETA on a fix? This bug is a serious impact on my job. I work on a web application that spawns threads. While I'm debugging the stack focus will disappear then once I select the stack again and expand the tree, the window will refresh before the mouse can even get to the code snippet to do some inspection. I go up to get the focus back and it happens again. Needless to say sometimes it feels that just making sure the focus is correct is spending about 25% of my time. If there is a valid workaround what is it?
> If there is a valid workaround what is it? Not showing thread groups, see comment #9.
(In reply to comment #18) > > If there is a valid workaround what is it? > > Not showing thread groups, see comment #9. This workaround didn't work for me. I am facing the same frustration with this bug.
The work around is not a valid work around. I have the following options with this bug: 1. Endure the pain of refinding my stack trace so I can step through the code or 2. Endure the pain of restarting my server due to it crashing. The server never crashes when I am not sorting by Thread Groups. If you want I have multiple crash logs from Weblogic that I can attach. What option would you want to constantly be encountering?
Is there any update to this issue? This issue is becoming more of a problem as my server keeps crashing when trying to debug automated test cases before it even gets to the break point. Is there a way that the importance can be raised?
The bug is infuriating. It makes any debugging absolutely impossible, if the application has hundreds of threads. Refreshing the view is not an option: how do you find the thread amongst 400 others? This bug is a major one for years. I guess I will waste my weekend and dug into the source to have some fix since even normal work is not possible.
We see this issue with Eclipse 3.6.0.v20100602, while debugging code running on Weblogic 10.3.3. The issue appears to be workspace related, and it starts occurring after prolonged use of the same workspace for daily development after a period of several days or weeks. Once it starts happening it consistently occurs everytime you start the debugger. If you create a new workspace but using the same code, the issue goes away (for another period of days or weeks). If you keep the same workspace but startup with -clean and restart without -clean, this also fixes the issue (for another period of days or weeks until it comes back). I suspect there is something in the workspace metadata that gets corrupt or out of sync that causes the issue. It doesn't seem to be caused by code that you're debugging or any particular application behavior (because it goes away if you do a -clean or create a new workspace with the same source)
This is killing me. It started around v3.2, but I could never find this bug to update. It seems like it is happening more and more and more. Right now, I can't even step more than 2-3 times before the thread I'm in disappears from the stack trace and re-appears moments later. Then I have to re-select the thread or sometimes expand the thread and select the top most method in the stack call. To be clear, I'm not using any server debugging and I'm not using stack groups. Please make this a P1 and fix it.
I think this can be closed as a dupe of bug 229536. In 229536 we updated the selection policy to *not* allow the selection to change even while stepping. This fix has been available since 3.7. Aaron, what version of Eclipse are you using?
I will look at that. I'm running 4.2.1
I just looked at that thread and that says "long-running" this is just normal stepping, nothing long. That says they fixed it not work around which they definitely did not. It is getting worse and worse every newer version of eclipse. The problem happens exactly like people are describing in this thread.
(In reply to comment #27) > I just looked at that thread and that says "long-running" this is just > normal stepping, nothing long. That says they fixed it not work around which > they definitely did not. It is getting worse and worse every newer version > of eclipse. The problem happens exactly like people are describing in this > thread. Long-running was the most common way to see the problem, but the fix there would prevent the selection from being stolen regardless of the length of a given operation. An example program that demonstrates the problem would help here, as I have not seen this problem in a long time.
everything that I debug is inside a huge project. I'm working on a smaller project in my free time. I will see if I can recreate it there.
Given the intermittent reports, my guess is that there's a race condition in the viewer. If you are able to reproduce the problem while having tracing turned on with the following options, we might be able to puzzle out what's going wrong. Just save the trace to a file and attach it to the bug (annotate the log to point to the failure if possible). org.eclipse.debug.ui/debug = true org.eclipse.debug.ui/debug/viewers/deltas = true org.eclipse.debug.ui/debug/viewers/contentProvider = true org.eclipse.debug.ui/debug/viewers/updateSequence = true org.eclipse.debug.ui/debug/viewers/stateSaveRestore = true org.eclipse.debug.ui/debug/viewers/presentationId=org.eclipse.debug.ui.DebugView
please tell me how to do what you are talking about... or what those lines you pasted are all about. This happens to me CONSTANTLY. Makes a couple minute debug into an agonizing hour long affair.
(In reply to comment #31) > please tell me how to do what you are talking about... or what those lines > you pasted are all about. This happens to me CONSTANTLY. Makes a couple > minute debug into an agonizing hour long affair. Add the mentioned options to our .options file when you launch Eclipse with the -debug option. For more information see: http://wiki.eclipse.org/FAQ_How_do_I_use_the_platform_debug_tracing_facility%3F
This is happening for me consistently as well. Either with web applications running in Tomcat, to a simple stand-alone JUnit test run. At least in my case, turning off "Show Thread Groups" seems to be a valid work-around, but something that should properly be fixed regardless. As noted, this bug seems to be a confusing mix of different and intermittent reports. How can we better manage this - without creating additional bugs for each potential cause, only to be closed as duplicates? I, for one, will be happy to "own" the report for at least this scenario that I can reproduce, and will provide debugging and test fixes until it is properly resolved. 4.3.1 / M20130911-1000
This problem is happening to me in the eclipse that ships with Android ADT, I think the eclipse version is 4.21. I'm trying to debug some native code for android, and every time I hit a breakpoint and I start stepping the focus goes away to some other thread and it takes me a few seconds to find where is the thread I was debugging, then click on it, to step once and lose the focus again, very very frustrating!! I have tried the suggested workarounds in this thread but they don't work for me. I have tried activate/deactivate the Show Thread Groups and had no effect. I have tried restart eclipse with -clean and restart again and no effect either. This bug should be a priority, it makes debugging impossible.
Created attachment 237167 [details] Test case I also met this frequently, so I created a simple sample to reappear this. share it and hope it helps. Reappear Steps: 1.Import SelectTest.zip as a java project; 2.Break at ATest.java:Line 8; 3.Launch debug; 4.Set selection on thread [main] and collapse [Thread-0]. Sometimes it begins like the above while sometimes not, if not, set to that. 5.Resume(F8) Then the selection is not on track anymore.
After days struggling with this infuriating problem I found this SO thread: http://stackoverflow.com/questions/10444664/eclipse-cdt-multithreaded-debugging-not-optimal-how-does-one-run-threads-exclu If I send to gdb a "set scheduler-locking on" after hitting the breakpoint, then I can happily step through my function, then before hitting resume I have to send "set scheduler-locking off" to gdb. Having to do this at every breakpoint it's not optimal but at least it allows you to be focused on the function you are debugging until you want to continue. Notice that my scenario was debugging Android native applications with CDT.
I have suffered for years with this issue, is there really no solution in the making? Thanks
Please finally tackle this issue. It's slowing down dozens of developers here.
One year since the last comment, and I get this problem again with eclipse 4.6.0...
We too, very frequently actually, as our application has a lot of threads coming and going ...
Still problem with Eclipse 4.7.3a
(In reply to Wang Chaos from comment #35) > Created attachment 237167 [details] > Test case > > I also met this frequently, so I created a simple sample to reappear this. > share it and hope it helps. > > Reappear Steps: > 1.Import SelectTest.zip as a java project; > 2.Break at ATest.java:Line 8; > 3.Launch debug; > 4.Set selection on thread [main] and collapse [Thread-0]. > Sometimes it begins like the above while sometimes not, if not, set to > that. > 5.Resume(F8) > > Then the selection is not on track anymore. Thanks for the example, still in 4.9 HEAD. Simeon, I wonder if this is also something interesting for us. Has nothing to do with short leaving threads, here is either the DefaultSelectionPolicy or our beloved TreeModelContentProvider updates which seem to do weird things.
(In reply to Andrey Loskutov from comment #42) > Has nothing to do with short leaving threads, > here is either the DefaultSelectionPolicy or our beloved > TreeModelContentProvider updates which seem to do weird things. Will have to check. Probably TreeModelContentProvider.
Have same problem with 4.7.3a. I use CDT. I find the following work around manageable for me (ideal would be a fix): 1) wait for break point to hit 2) select the right thread for your break point 3) in "Debug" tab, click on "View Menu" 4) then select "Layout", "Breadcrum" 5) step as needed 6) when done undo your selection ("Debug" tab, "View Menu", "Layout", "Automatic"
Can we please put some priority here? My application suffers from this issue as well it makes debugging SO much annoying...
@Simeon Will you be interested in working on this?
Some more input: When watching the threads, I can see that the current thread (with breakpoint) suddenly disappear from list for a few seconds, and the reappear.
It would be nice if people who run into Debug View problems can try working with latest 4.9 release, there have been some fixes in this area: * bug 285130 (4.8 M1) * bug 519433 (4.8 M1) * bug 534319 (4.9 M2) * bug 535686 (4.9 M2) Still open issues I'm aware of, that me and Andrey are trying to address: * bug 537903 (JDI evaluation related only, caused by client code so not part of standard Eclipse) Also note that I have no idea about CDT. It may have problems on top of platform debug. I'll look into the case quoted by Andrey, see comment 42. Its fairly different than what we have touched so far.
Do you have a download link for a version that contains these fixes so we can try it out?
(In reply to Markus Mising name from comment #49) > Do you have a download link for a version that contains these fixes so we > can try it out? 4.9 should be available for download in the next days. If you wish to try right away, you can check with a 4.10 integration build. E.g.: http://download.eclipse.org/eclipse/downloads/drops4/I20180913-0415/
(In reply to Andrey Loskutov from comment #42) > (In reply to Wang Chaos from comment #35) > > Created attachment 237167 [details] > > Test case > > > > I also met this frequently, so I created a simple sample to reappear this. > > share it and hope it helps. > > > > Reappear Steps: > > 1.Import SelectTest.zip as a java project; > > 2.Break at ATest.java:Line 8; > > 3.Launch debug; > > 4.Set selection on thread [main] and collapse [Thread-0]. > > Sometimes it begins like the above while sometimes not, if not, set to > > that. > > 5.Resume(F8) > > > > Then the selection is not on track anymore. > > Thanks for the example, still in 4.9 HEAD. Simeon, I wonder if this is also > something interesting for us. Has nothing to do with short leaving threads, > here is either the DefaultSelectionPolicy or our beloved > TreeModelContentProvider updates which seem to do weird things. I think the bug here is: > > Sometimes it begins like the above while sometimes not, if not, set to The rest is standard behaviour. If the user explicitly collapsed a thread, the thread will not be switched to after the currently suspended thread is resumed. I'm guessing this is so that Eclipse does not interfere with the work flow of the user. I'm checking this "sometimes" out. Unfortunately its *rare*. I saw it the first time I tried to reproduce, maybe its tied to the Debug View not being active, or the ominous switch perspective (on breakpoint hit) dialog.
4.9 is available now - http://download.eclipse.org/eclipse/downloads/drops4/R-4.9-201809060745/
I've have tried the new 4.9RC1 and cannot reproduce any problem (happy face). For me at least all concerns are taken care of! Thanks to all involved.
(In reply to Kenneth Styrberg from comment #53) > I've have tried the new 4.9RC1 and cannot reproduce any problem (happy face). > For me at least all concerns are taken care of! > Thanks to all involved. If you run into issues, please let us know. Selection problems (so e.g. no active F8/resume button) me and Andrey are aware of (in standard Eclipse IDE, working with Java): 1. When hitting a breakpoint in a non-debug perspective, there is a dialog that asks if Eclipse should switch to a debug perspective (the user choice can be remembered, so usually this is a one-time dialog). 1.a) We had problems when choosing "No", not 100% sure if the problems were fixed. 1.b) We still have a problem when choosing the option to switch to the debug perspective. 2. Hitting a breakpoint while the Debug View is not open, or while the Debug View is hidden. 3. Hitting a breakpoint while Eclipse is not the focused window. 4. Spamming debug and resume, so that one small snippet is debugged over and over again in a fast succession. Overall the above don't affect everyday debugging too much so we've not looked into details.
(In reply to Simeon Andreev from comment #51) > (In reply to Andrey Loskutov from comment #42) > > (In reply to Wang Chaos from comment #35) > > > [...] > > > > > > Reappear Steps: > > > 1.Import SelectTest.zip as a java project; > > > 2.Break at ATest.java:Line 8; > > > 3.Launch debug; > > > 4.Set selection on thread [main] and collapse [Thread-0]. > > > Sometimes it begins like the above while sometimes not, if not, set to > > > that. > > > 5.Resume(F8) > > > > > > Then the selection is not on track anymore. > > > > [...] > > I think the bug here is: > > > > Sometimes it begins like the above while sometimes not, if not, set to > > [...] > > I'm checking this "sometimes" out. Unfortunately its *rare*. I saw it the > first time I tried to reproduce, maybe its tied to the Debug View not being > active, or the ominous switch perspective (on breakpoint hit) dialog. As far as I can tell, the "sometimes" is only if the Debug View was not open (at all). If the Debug View is not open, it will not listen to debug events (thread suspends). Once the debug target is installed (in particular JavaDebugTargetProxy.doInstalled()), *one* suspended thread is expanded and that's all. Resuming this thread will not expand other threads, since none were expanded at any point. Maybe we can improve this; when the JavaDebugTargetProxy.doInstalled() detects a suspended thread, all suspended threads in the debugee could be expanded. We've had problems with the doInstalled() code though (bug 491174). I'm not sure if we want to touch this, it sounds somewhat risky.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
