Community
Participate
Working Groups
4.19 When a breakpoint is hit, all threads are suspended; reasonable. Previously the Debug Window showed the thread containing the hit breakpoint as the selection. Now the Debug Window shows the first thread, i.e. main as the selection. So if the breakpoint is in the worker thread, the user is initially puzzled that a break has occurred in a wait and must then scroll to find the true break.
Note: *all* threads are not suspended *by default* on breakpoint hit. Ed, please provide a simple example application to reproduce & steps to reproduce, including *how* do you create a breakpoint.
I have been recently using worker Threads more and so I changed the new-breakpoint preference to suspend VM and I am gradually discovering that suspend VM is not fit for my purpose. I just want stop/go for all user threads to avoid worker threads running away and potentially timing out during debug of another thread. It seems this is not supported. (By user thread I mean nearly all threads; only debug support/GC/... threads excluded.) a) Stop is not consistent. When I change preference to suspend VM I want ALL breakpoints to switch. This is not what the preference page comment says, but does actually seem to be what happens. Obviously if only new breakpoints suspend VM then I have a hotch potch of old / new breakpoint behaviours. b) Resume is not consistent. I want all threads to resume, so it is a pain to have to remember to keep selecting the threads-parent before hitting Resume. c) as per the original report, when all threads stop, quite which threads are expanded to show their stack is a bit random; usually main and a relevant worker, but not always, and often the selection is not on the breakpoint hit thread. ---- The traditional stop-single thread seems fine. An option to stop entire VM but resume just one thread may be useful sometimes, but it seems rare. The option to stop/resume the 'whole' VM seems like the other useful use case, perhaps with a preference option to select which threads are considered user threads that stop and which are system threads that do not.
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.
