[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] DSF lockup with debugger-assisted run
|
Hi Volodoya,
I think the correct method to handle this is to invent a new state:
"intederminate" in the GDB debugger integration (it could also be pushed
into the DSF IRunControl service). If target is in this state, then the
UI would know not to fetch the stack data. This is how we solved a
similar problem in the Wind River debugger. Otherwise, you could just
handle the problem in the stack service and decide not to return any
stack frames.
Cheers,
Pawel
On 09/30/2010 08:28 AM, Vladimir Prus wrote:
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
