Community
Participate
Working Groups
When a StackOverflow occurs, the debugger sometimes goes incredibly slow as it endeavours to proceed without any memory. It is generally impractical to actually use the debugger. Suggest: run the debugger with a 75% limit on the stack usage, so that the remaining 25% can be released to assist in debugging the overflow.
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 repeatable problem that almost all developers will encounter periodically. CLOSED WONTFIX is not an appropriate solution.
Strange. History shows REOPENED. More practical. While the debugger is inching its way towards the inevitable stack overflow, the Suspend bitton is ignored preventing the user regaining control. Surely there should be an isCancelled() check per stack push.
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.
Still no triage from a relevant committer.
