Re: Stacktraces in the SourceWindow

[Mike Cvet <mcvet at redhat dot com>]

On Fri, 2006-09-08 at 14:20 +0200, Mark Wielaard wrote:
> On Thu, 2006-09-07 at 17:26 -0500, Phil Muldoon wrote:
> > <bluesky>
> > 
> > If we could store the stack-trace saying during a syscall, we could 
> > print to the log window what function the thread was in when the syscall 
> > entered, as well as all the usual information. We could code up a GTK 
> > method to make the function click-able in the monitor log, and then it 
> > would open a source window showing the code context of where the syscall 
> > happened. If we stored the whole stacktrace for each log event in the 
> > ui, we could even show the user how it got to that point in the code. We 
> > 'd have to have a circular buffer though, and eventually stack traces 
> > would be discarded as memory demands dictate.
> > 
> > </bluesky>

Awesome! I expect this information to be useful all over the monitor; as
you said this can be plugged into syscall observers, we could create new
Filters and Actions, and as discussed last night, properly update entry
function information in the thread view.

But as Elena noticed (the line #0 thing) there are still plenty of bugs
yet. And tons of work to do in the SourceWindow and the stack-related
classes it uses.

> 
> Nice. That does probably slow down programs we are tracing even more
> though. So it should probably not be on by default. You also need to
> think about libraries that might be loaded/unloaded dynamically. How
> would that interact with the stacktraces? It means that at a later time
> the original stacktrace might not be valid, or that it might not be
> possible to find the actual code back.
> 

You're absolutely right - currently the stack tracing is a fairly
expensive operation and for the example trace I showed yesterday with
the seven stack frames (the bottom two belong to glibc), there were 45
ptrace calls routed through our PtraceThread (*grumble*).

So when this information is used in the monitor we'll just have to
figure out a way to do it with minimal impact on tracing and monitor
operation in general. We'll obviously want to do as few calls as
possible to the unwinder, and store as much information as we can.

You raise a another good point though - we'll have to figure out a way
to keep the stack trace current. Ugh.

> Another bluesky idea. Seeing the stack trace addresses I thought it
> would be nice if anywhere in the gui where you have a code address you
> could simple add a CodeObserver by right-clicking, or some other
> mechanism to the current Task or the whole Process. That way you can
> quickly start with breakpointing in the gui and don't have to do any
> code/line/address conversions (yet).
> 

Cool! Sounds like we'd better start working up some enhancement bugs =)

- Mike