Hi Ken,
The StackFrameVMNode and AbstractLaunchVMProvider contain the following
optimization:
- When a a suspended event is received, StackFrameVMNode requests
that only the top stack frame be repainted in Debug view.
- At the same time AbstractLaunchVMProvider.handleEvent() queues an
event (FullStackRefreshEvent) to be generated with a fixed delay
(200ms).
- When FullStackRefreshEvent is posted after the delay,
StackFrameVMNode requests that all stack frames be refreshed in Debug
View.
- If a resumed or another suspended event is received before the
FullStackRefreshEvent is posted, the FullStackRefreshEvent is canceled.
The optimization is intended to minimize refreshes when debugger is
stepping fast, but it seems that in your case it gets into some kind of
a cycle. If you set breakpoints in the places where this event is
queued, I think you should be able to figure out what causes the cycle.
Cheers,
Pawel
ken.ryall@xxxxxxxxx wrote:
DSF folks,
While working on our DSF integration we occasionally get in a state
where the stack frame nodes in the Debug View constantly refresh. This
usually happens the first time execution is suspended and the stack
frames become available. Sometimes it will append on the next suspend.
It happens even if we don’t send a suspend event and then expand the
parent thread node manually. Once the refreshing starts it will
continue even if you collapse the tree items back up to the launch and
then expand then out again.
We don’t see this when running the dsf/gdb debugger so we must be doing
something a little wrong. Before I spend a lot more time looking into
this I thought I would ask if anyone had run into it before.
Thanks - Ken
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|
