Community
Participate
Working Groups
Build: 3.3 M4 I set a Java exception breakpoing on StackOverflowError, and then debugged an application that had a stack overflow. The debug session froze, and I left it for about ten minutes at 100% CPU usage but no response in the debug view. Note Eclipse itself was not hung, but the debug view was unresponsive and I was unable to see any of the stack frames in the suspended thread. I will attach a stack trace that shows 20+ threads, which was taken after several minutes of waiting.
Created attachment 56939 [details] Stack trace
There is an entry in the 'readme' regarding stack overflows: "Unable to debug stack overflows: If a debug session suspends on a java.lang.StackOverflowError exception (due to an exception breakpoint), the debugger may not be able to retrieve any debug information from the target JVM. As well, the debugger may not be able to reliably interact with the target JVM past this point. (bug 19217)"
Interesting... the symptoms appear to have changed. I don't get any errors in the log file - it just pins at 100% CPU for a long time. I'm sure this worked at some time in the past... I now have a reproducible bug that causes a stack overflow and I can't find any way to see the stack to know where the problem is!
Created attachment 57092 [details] Stack while copying clipboard In my ongoing efforts to find the cause of my stack overflow (bug 169943), I tried setting a StackOverflowError breakpoint, but *not* expanding the thread in the debug view. Then, I selected "Copy Stack" from the process context menu. This showed progress for awhile, and after a minute I clicked cancel. I then went to work on another machine, and twenty minutes later the "Copy Stack" operation was still going. This attachment shows the VM state at this point after the copy stack has been working for twenty minutes. It seems debug at least needs to fail more gracefully when faced with a stack overflow.
After two hours the "copy stack" dialog was still blocking me, so I had to kill the process.
*** Bug 188072 has been marked as a duplicate of this bug. ***
Nothing planned for 3.3
This is a dupe of 19217, but I will leave it open in case we want to investigate Darin's suggestion to not try and retrieve so many frames - bug 258416 comment #4
(In reply to Michael Rennie from comment #8) > This is a dupe of 19217 No it isn't. Bug 17217 is WONTFIX. This is an ongoing (Neon M4) problem. Handling a StackOverflow is clearly challenging but locking up Eclipse is a CRITICAL no-brainer. Why is there no magic key sequence (ESC or CTRL+\ or ...) that causes Eclipse to suspend troublesome worker threads and give the user back some control?
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. As such, we're closing this bug. If you have further information on the current state of the bug, please add it and reopen this bug. 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.
This is a long standing problem affecting most JDT Debug users from time to time.
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.
