Re: [DynInst_API:] How to use DyninstAPI to get thread/process call stack in case of a signal delivery

[Bill Williams <bill@xxxxxxxxxxx>]

On 04/21/2014 10:26 AM, JiangJie wrote:
> 
> 
>  > Date: Mon, 21 Apr 2014 09:59:44 -0500
>  > From: bill@xxxxxxxxxxx
>  > To: yangtzj@xxxxxxxxxxx
>  > CC: dyninst-api@xxxxxxxxxxx
>  > Subject: Re: [DynInst_API:] How to use DyninstAPI to get 
> thread/process call stack in case of a signal delivery
>  >
>  > On 04/20/2014 09:02 AM, JiangJie wrote:
>  > > Hi Ray,
>  > >
>  > > Yes it's possible to use ProcControlAPI directly to just intercept 
> signal.
>  > >
>  > > But my purpose is to collect the thread/process's callstack in case of
>  > > a signal delivery,
>  > > in order to know the context where the signal is raised.
>  > > So I would like to call some API like BPatch_thread::getCallStack()
>  > > in the registered event callback for ProcControl
>  > >
>  > > My question is, if I use
>  > > ProcControlAPI->Process::registerEventCallback(EventType::Signal,
>  > > my_signal_cb)
>  > > to register a callback to intercept a signal, how to get the callstack
>  > > in the registered callback?
>  > > Is it possible to make use of BPatch_thread::getCallStack() in the
>  > > registered signal callback?
>  > > Or is there any other solution?
>  > >
>  > > Regards,
>  > > Jie
>  > >
>  > Jie--
>  >
>  > I'm assuming that you just want a debugging call stack, and aren't
>  > aiming for any sort of recovery.
>  >
>  > If you set DYNINST_DEBUG_CRASH in your environment, that should produce
>  > a stack trace and register contents. You can set that variable to the
>  > location of your preferred gdb, which will attempt to attach gdb to the
>  > mutatee, or set it to "sleep", which will leave the mutator spinning in
>  > a sleep loop. Any other value should produce a core file (if your
>  > environment is set up to allow them).
>  >
>  > Hope that helps.
>  >
>  > --bw
>  >
> 
> Bill,
> 
> Do you know STAT?
> One main functionality of STAT is to collect call stacks from target 
> processes on demand,
> on the base of DyninstAPI or StackWalkerAPI.
> But STAT only supports on-demand collecting of call stacks.
> Actually what I am planning to do is to extend STAT to support 
> event-based collection of call stacks,
> e.g, to collect call stacks in case of SIGSEGV. Since I still want to 
> reuse STAT's infrastructure
> ( especially for parallel jobs ), I would prefer to collect the target 
> mutatee's call stacks in the context of STAT Backend process and then 
> send it back to STAT front end.
> 
> I haven't tried your solution yet and have no idea if it works for my 
> purpose.
> But I think a signal handler callback is more intuitive for me.
> 
Jie--

I do in fact know STAT, including its internals, a fair bit. And this
should be a fairly obvious extension if you take a look at the STAT
back-end code, as everything it's doing is with ProcControlAPI and
Stackwalker directly. You'd simply want to register your signal handler
callback with ProcControl, and have that callback trigger a stack walk
with the back end's Walker.

If Dyninst is involved in any extension of STAT, something is likely
very wrong with the design; the current version of STAT solely depends
on Dyninst subcomponents, and adding Dyninst itself would break the
existing STAT process control model.

> Jie
> 
> 
> 
> 


-- 
--bw

Bill Williams
Paradyn Project
bill@xxxxxxxxxxx