dtrace discuss - Dec 2005 - ustack() issues && correlating SIGSEGV activ ity?

Hi Ryan,
> Does anyone happen to know why the ustack() doesn''t show lex, 
> yak, main 
> and _start?
A quick look with the source browser seems to indicate that _rt_boot is code
executed very early in the lifetime of your process by ld.so.1. What seems
to be happening is that ld.so.1 has allocated some memory before DTrace got
control of your process - long before main() was called. As such, the malloc
entry probe never fired and this block is missing from your array.

ISTR a thread a while back where Adam described where in the process''s
lifetime DTrace got control of it, and that there was an -x option to tweak
this. I don''t seem to be able to find this now, and can''t see
it in the
docs, so maybe I made it up. I''m sure someone better qualified than me
can
provide the right pointer.

Anyway, a good way to avoid this would be to set a variable when you enter
main(), and add this to your predicate - this would mean you''d be
insulated
from all the strangeness going on before main() is called.
> Also -- is there a way to use DTrace to trace 
> access to memory 
> and  correlate that back to the instruction and function that 
> accessed it 
> (e.g., finding the culprit of a SIGSEGV without gdb)?
DTrace can''t realistically hook into every memory access (unless you
know
your assembly and fancy some instruction level tracing, or know you''re
looking for a bad memcpy), and it isn''t really a postmortem debugging
tool -
your best bet for this would be to use mdb (if the process has already
crashed, and you have a core file) to get the stack and have a poke around
the entrails, or to use the debugging options in libumem to narrow down any
access violations if you have a reproducible test case. Adam''s blog has
a
good example of using libumem to track leaks; looking for bad memory access
is similar.

However, once you''ve narrowed down where your crash might be, DTrace
and
particularly speculations are very powerful tools for providing more
information about the crash scenario.

-- 

Philip Beevers
Fidessa Infrastructure Development

mailto:philip.beevers at fidessa.com
phone: +44 1483 206571


******************************************************************    
This message is intended only for the stated addressee(s) and
may be confidential.  Access to this email by anyone else is
unauthorised. Any opinions expressed in this email do not
necessarily reflect the opinions of royalblue. Any unauthorised
disclosure, use or dissemination, either whole or in part is
prohibited. If you are not the intended recipient of this message,
please notify the sender immediately.
******************************************************************