Community
Participate
Working Groups
This defect is a side effect of the optimizations added by fixing bug 202553. There are a couple of bugs related to this behavior. One is the fact that the GDB debugger doesn't return the list of threads when stepping fast: (bug 234464). When stepping fast, this can cause the debug view to collapse. However, if all went well in the view model implementation the suspended event should cause the list of threads to be refreshed, and eventually lead to stack frames being shown and one being selected. The other bug I believe is in the view model cache itself. There seems to be a race condition remaining where the update for the suspended event is somehow overridden by the update for the running event. This needs to be properly traced, diagnosed, and corrected.
See also bug 235452.
I think this happens when a FullStackRefreshEvent is issued, although we are still stepping, ie. when a step takes longer than the delay timeout. The handling of the full stack refresh event can then interfere with the handling of the last suspended event resulting in a collapsed thread. When setting the delay timeout (LaunchVMProvider.FRAME_UPDATE_DELAY) to a higher value (e.g. 500), it does not happen anymore (or at least less likely). A workaround seems to be to add the EXPAND and SELECT flags to the deltas for the full stack refresh event, so that the top stack frame gets selected again.
(In reply to comment #2) > A workaround seems to be to add the EXPAND and SELECT flags to the deltas for > the full stack refresh event, so that the top stack frame gets selected again. Adding these flags to the refresh event works because it gives the service a second chance to retrieve the list of threads when the target is suspended. I'm almost done with the PDA mult-threading, if we're not able to reproduce that with PDA, then I think we can safely close out this bug and just leave the GDB bug open.
