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

[Vladimir Prus <vladimir@xxxxxxxxxxxxxxxx>]

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

> 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.

But that would still mean that the (bogus) stack is fetched, and depending on 
target speed, is displayed for some time, before disappearing when session
terminates.

In fact, we've just run into a situation where launch sequence does:

	-target-select
         ......
        -exec-continue

and there's kinda bogus stack fetched and displayed right after -target-
select. The stack is bogus because after -target-select, target is stopped
in a random place so the backtrace is not necessary valid or even for
the application we're about to debug.

Do you know about any way to suppress stack fetch there? I believe it's
trigged by "*stopped" response from -target-select which is then
translated into ContainerSuspendedEvent. Does DSF have a way to
install global event filter, or is there some other way?

- Volodya