Community
Participate
Working Groups
One of the most annoying things about the Eclipse debugger is that if you hit the Pause button on a running program and then try to view variables in a higher stack frame, you get this message: "This thread has been manually suspended and therefore object details are unavailable." I don't know of a technical reason why object details would not be visible if you manually suspend, vs. setting a breakpoint. It's 2020... can this issue please get fixed?
Weirdly if you step even one line in the deepest stack frame, variables are suddenly visible in all higher stack frames. I suspect then that the intent of this is to prevent inconsistent state from being displayed in the debugger, if the currently-executing statement is in the middle of updating multiple values? It would be better to simply display what's in the variables at the moment the debugger was paused, whether the values are inconsistent or not.
(In reply to Luke Hutchison from comment #0) > It's 2020... can this issue please get fixed? What's special about 2020 suggesting that requests must be implemented immediately? :) (In reply to Luke Hutchison from comment #1) > Weirdly if you step even one line in the deepest stack frame, variables are > suddenly visible in all higher stack frames. Yea, that's the workaround, which perhaps should be better popularized for the time being (I'd call it the top stack frame, though - that's how I see stack frames in the Debug view ...).
It's 2020 meaning this bug is extremely ancient... Personally it has been causing me grief for at least 18 years (the earliest I remember using Eclipse, if I remember right)... I can't be the only one that gets frustrated with this. I don't understand why there should not be a fairly straightforward bugfix, although I know nothing of why this is a limitation in the first place, so maybe I'm oversimplifying.
Normally we start thinking about a solution when someone reports a situation as a problem. Had you reported the issue 18 years ago, we would probably be in a different situation. However, this is day one of this bug. As for an assumably straight-forward fix you may expect my answer: if you help us fixing it, chances are significantly increasing for this to be fixed in the 2020-06 release.
I wasn't trying to sound snarky. You are right. I typically report bugs in Eclipse as soon as I find them -- I have reported a large number over the years; you have seen them. I didn't think to report this as a bug, I just thought it was a temporary limitation that would get fixed in time (because it was common and conspicuous). I have tried digging into the Eclipse codebase before, and found it very hard to grasp, so I have mostly left fixes to the experts.
I *believe* (haven't looked into the code yet) this is a limitation of the debugger API, if we don't announce a breakpoint, JVM doesn't supply us the data for variables. I also believe this is a very good request, I wonder why wasn't that requested earlier. As hitting a "suspend" may stop at any line during execution, one possibile workaround would be to run *automatically* a "step over" right after the suspend, shouldn't be a big difference for the user where we stop. I fear however many debugger tests will go mad if we do so (different events, debugger state etc). So probably a "smart suspend" option would be needed to avoid that (and for possible compatibility break or issues with custom debuggers based on Java debugger). Sarika, Simeon, Till, WDYT?
I agree, simulating a single "step into" right after pausing should do the trick. I don't think many debugger tests will try to pause a program at a specific time point rather than at a specific breakpoint. A test based on arbitrarily pausing the program would be a racy test -- so I don't see your proposed solution as causing test failures.
(In reply to Andrey Loskutov from comment #6) > I *believe* (haven't looked into the code yet) this is a limitation of the > debugger API, if we don't announce a breakpoint, JVM doesn't supply us the > data for variables. > > I also believe this is a very good request, I wonder why wasn't that > requested earlier. > > As hitting a "suspend" may stop at any line during execution, one possibile > wor > Simeon WDYT? I'll have to take a look first, no idea at first glance.
(In reply to Luke Hutchison from comment #7) > I don't think many debugger tests will try to pause a program at a specific > time point rather than at a specific breakpoint. A test based on arbitrarily > pausing the program would be a racy test -- so I don't see your proposed > solution as causing test failures. Debugger tests expect often some specific state / events received after resume, but doing an extra "step" produces of course different state & events as just one "resume".
(In reply to Andrey Loskutov from comment #6) > I *believe* (haven't looked into the code yet) this is a limitation of the > debugger API, if we don't announce a breakpoint, JVM doesn't supply us the > data for variables. > > I also believe this is a very good request, I wonder why wasn't that > requested earlier. > > As hitting a "suspend" may stop at any line during execution, one possibile > workaround would be to run *automatically* a "step over" right after the > suspend, shouldn't be a big difference for the user where we stop. > > I fear however many debugger tests will go mad if we do so (different > events, debugger state etc). So probably a "smart suspend" option would be > needed to avoid that (and for possible compatibility break or issues with > custom debuggers based on Java debugger). > > Sarika, Simeon, Till, WDYT? Here I am not sure we want to this for each resume. We can store and check if it was "Paused" but we can hit into concurrency issues as well.
(In reply to Andrey Loskutov from comment #9) > Debugger tests expect often some specific state / events received after > resume, but doing an extra "step" produces of course different state & > events as just one "resume". Right, but there's no need to do the extra "step-in" if the debugger stops at a breakpoint. The only time it is necessary to do the extra "step-in" is if you pause the running program at an arbitrary point -- which unit tests probably won't be doing, since any test like this wouldn't be able to guarantee that the running program would stop at any specific place in the program. If a unit test does test pausing of a running program without a breakpoint, it's not going to hurt the unit test to run one extra "step-in" after that, since the test could have stopped at any line anyway.
I see the issue that there might be thousands of threads, so doing this when stopping the whole jvm is too expensive. Maybe it would be possible to do it on-demand, when you klick on a Thread But there is the issue that a thread might be in native method (think Thread.sleep()) so even one step can take a longer time. I suspect the same problem exists probably if the JIT has onrolled some loops so no safepoint is reached for a longer time - i once had issues with this when I tried to force a GC)
(In reply to Till Brychcy from comment #12) > Maybe it would be possible to do it on-demand, when you klick on a Thread The information from lower stack frames is only ever needed for manual examination, so this would be totally acceptable. > But there is the issue that a thread might be in native method (think > Thread.sleep()) so even one step can take a longer time. I just tried stepping into Thread.sleep(), and even while the thread was still sleeping, as soon as I clicked the Pause button in the debugger, the thread was paused again (it didn't wait for the native method to return). I don't know what happens in general if you hit Pause while a native method is running, and then the native method tries to return while the debugger is paused (is the native thread paused by the debugger too?). But assuming this doesn't cause a problem, it should be fine to add a timeout to the "step-into" operation, so that if the operation has not returned by the end of the timeout, the thread is simply paused again and the status quo message is shown: "This thread has been manually suspended and therefore object details are unavailable."
Any updated thinking on this issue? I'm running into this again today repeatedly.
Andrey, why does the JDT debugger not allow context when suspending the JVM? I have no problems to retrieve this information with jdb: ...:/home/sandreev/tmp/tmp2$ cat TestLoop.java public class TestLoop { static void bubbleSort(int[] arr) { int n = arr.length; int temp = 0; for(int i = 0; i < n; i++) { for(int j = 1; j < (n - i); j++) { if(arr[j - 1] > arr[j]){ temp = arr[j - 1]; arr[j - 1] = arr[j]; arr[j] = temp; } } } } public static void main(String[] args) { int n = 1_000_000; int[] arr = new int[n]; java.util.Random r = new java.util.Random(); for (int i = 0; i < n; ++i) { arr[i] = r.nextInt(1000); } bubbleSort(arr); } } (taken from https://www.javatpoint.com/bubble-sort-in-java, just have some number crunching to keep the JVM busy) ...:/home/sandreev/tmp/tmp2$ javac -g:vars TestLoop.java (compile with debug infos for variables) ...:/home/sandreev/tmp/tmp2$ jdb TestLoop Initializing jdb ... > run run TestLoop Set uncaught java.lang.Throwable Set deferred uncaught java.lang.Throwable > VM Started: suspend All threads suspended. > thread 0x01 main[1] locals Method arguments: arr = instance of int[1000000] (id=418) Local variables: n = 1000000 temp = 998 i = 980 j = 508514 main[1] quit IMO the first step would be to understand what the jdb and the JDT debuggers do differently, before we do anything for the JDT debugger.
