Re: [cdt-dev] DSF lockup with debugger-assisted run

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

On Tuesday 21 September 2010 20:59:52 Pawel Piech wrote:

> I think handling the rejectedExecutionException as you did is the 
> correct fix.  Though I think additional cleanup should be done to 
> propagate the error to the caller.  Can you please create a bug for this?

Done: https://bugs.eclipse.org/bugs/show_bug.cgi?id=325943

How do you suggest to handle errors? IIUC, for the case of final launch
sequence, Sequence.fRequestMonitor is not actually used by the clients,
so even if we call setStatus on it, nobody will notice.

And, more importantly, this is only about reporting of an issue. It's not
clear to me why =thread-group-exited results in almost-full DSF shutdown,
but debug view still shows GDB as running. 

> As far as the error stack trace.  I think I've seen something like this 
> before.  The best way to handle this would be to make sure that there is 
> an event event that's issued following GDB termination that causes the 
> Debug view to refresh and correctly show that there is no frames.  The 
> other question is to see why there is a dummy stack frame created with 
> this message.  I don't see an obvious place where it comes from.

The exact message, actually, is "<unavailable>" and it appears to come
from ThreadVMNode.java.

Thanks,

-- 
Vladimir Prus
CodeSourcery
vladimir@xxxxxxxxxxxxxxxx
(650) 331-3385 x722