dtrace discuss - Feb 2010 - How to detect all ways a program exits in time to resolve symbols?

Hi all,

Here''s a problem I''ve wrestled with off and on... I have an
aggregation
keyed off ustack(), and if the process exits before dtrace stops, I get
the usual hex garbage for the resulting stack frame printouts.

I know the usual way to deal with this is by stopping the process, but
proc:::exit occurs too late for that to stick (see, e.g.
http://www.mail-archive.com/dtrace-discuss at opensolaris.org/msg02123.html).
The solution given in that older message was to snag
syscall::rexit:entry, but that only catches normal exits. What is the
proper way to stop a process when it receives an unhandled signal or
aborts? There doesn''t seem to be anything like proc:::signal-unhandled.

I can''t grab the app with -p, so I''m just passing the pid as a
script
param. Also, it''s heavily multithreaded. Assertion failures can occur
in
multiple threads simultaneously, for example. While I can catch SIGABORT
it would be nice to only catch the one that actually kills the process,
along with any other unhandled signals...

Any ideas?
Ryan

Nudge?

Ryan Johnson wrote:
> Hi all,
>
> Here''s a problem I''ve wrestled with off and on... I have
an aggregation
> keyed off ustack(), and if the process exits before dtrace stops, I get
> the usual hex garbage for the resulting stack frame printouts.
>
> I know the usual way to deal with this is by stopping the process, but
> proc:::exit occurs too late for that to stick (see, e.g.
> http://www.mail-archive.com/dtrace-discuss at
opensolaris.org/msg02123.html).
>
> The solution given in that older message was to snag
> syscall::rexit:entry, but that only catches normal exits. What is the
> proper way to stop a process when it receives an unhandled signal or
> aborts? There doesn''t seem to be anything like
proc:::signal-unhandled.
>
> I can''t grab the app with -p, so I''m just passing the pid
as a script
> param. Also, it''s heavily multithreaded. Assertion failures can
occur in
> multiple threads simultaneously, for example. While I can catch SIGABORT
> it would be nice to only catch the one that actually kills the process,
> along with any other unhandled signals...
>
> Any ideas?
> Ryan
>
>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

On Wed, Feb 03, 2010 at 06:26:37PM +0100, Ryan Johnson
wrote:
> Hi all,
> 
> Here''s a problem I''ve wrestled with off and on... I have
an aggregation
> keyed off ustack(), and if the process exits before dtrace stops, I get
> the usual hex garbage for the resulting stack frame printouts.
> 
> I know the usual way to deal with this is by stopping the process, but
> proc:::exit occurs too late for that to stick (see, e.g.
> http://www.mail-archive.com/dtrace-discuss at
opensolaris.org/msg02123.html).
> The solution given in that older message was to snag
> syscall::rexit:entry, but that only catches normal exits. What is the
> proper way to stop a process when it receives an unhandled signal or
> aborts? There doesn''t seem to be anything like
proc:::signal-unhandled.
> 
> I can''t grab the app with -p, so I''m just passing the pid
as a script
> param. Also, it''s heavily multithreaded. Assertion failures can
occur in
> multiple threads simultaneously, for example. While I can catch SIGABORT
> it would be nice to only catch the one that actually kills the process,
> along with any other unhandled signals...
> 
> Any ideas?
If you use "dtrace -p process", then dtrace will use /proc to ensure
it
has an accurate symbol table before it completes processing.

This is limited to a single process, though.

Cheers,
- jonathan

On 2/12/2010 7:39 PM, Jonathan Adams wrote:
> If you use "dtrace -p process", then dtrace will use /proc to
ensure it
> has an accurate symbol table before it completes processing.
>
> This is limited to a single process, though.
>    
Ah, that''s very good to know. If -p grabs the process, though, I might 
have to give up my bad habit of running with dbx attached all the time.

Thanks,
Ryan