Matty
2005-Dec-21 17:19 UTC
[dtrace-discuss] ustack() issues && correlating SIGSEGV activity?
Howdy, I was playing around with the malloc/free D script provided by Philip Beevers: http://www.opensolaris.org/jive/thread.jspa?threadID=4224&tstart=15 And decided to change the free:entry probe from: pid24169::free:entry / sz[arg0] / { printf("Freeing %p (size %d)\n", arg0, sz[arg0]); sz[arg0] = 0; } to: pid24169::free:entry / ! sz[arg0] / { printf("[ * ] A bad function is Freeing memory at address %p\n",arg0); ustack(); } When I created a test program [1] and attempted to run the new script, I got the following output: $ dtrace -q -s foo.d -c ./fluffy fluff: 20a30 [ * ] A bad function is Freeing memory at address ff3f1298n ld.so.1`free ld.so.1`setup+0x13ac ld.so.1`_setup+0x3b0 ld.so.1`_rt_boot+0x88 Does anyone happen to know why the ustack() doesn''t show lex, yak, main and _start? 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)? Thanks for any insight, - Ryan -- UNIX Administrator http://daemons.net/~matty [1] $ cat fluffy.c void yak(char *fluff) { free(fluff); lex(fluff); } void lex(char *fluff) { free(fluff); } int main(int argc, char**argv) { char *fluff = malloc(1); printf("fluff: %0x\n",fluff); yak(fluff); }
Jonathan Adams
2005-Dec-21 22:41 UTC
[dtrace-discuss] ustack() issues && correlating SIGSEGV activity?
On Wed, Dec 21, 2005 at 12:19:13PM -0500, Matty wrote:> > Howdy, > > I was playing around with the malloc/free D script provided by > Philip Beevers: > > http://www.opensolaris.org/jive/thread.jspa?threadID=4224&tstart=15 > > And decided to change the free:entry probe from: > > pid24169::free:entry > / sz[arg0] / > { > printf("Freeing %p (size %d)\n", arg0, sz[arg0]); > sz[arg0] = 0; > } > > to: > > pid24169::free:entry > / ! sz[arg0] / > { > printf("[ * ] A bad function is Freeing memory at address %p\n",arg0); > ustack(); > } > > When I created a test program [1] and attempted to run the new script, I > got the following output: > > $ dtrace -q -s foo.d -c ./fluffy > fluff: 20a30 > [ * ] A bad function is Freeing memory at address ff3f1298n > ld.so.1`free > ld.so.1`setup+0x13ac > ld.so.1`_setup+0x3b0 > ld.so.1`_rt_boot+0x88 > > Does anyone happen to know why the ustack() doesn''t show lex, yak, main > and _start?Looks like tail-call optimization to me. Try: int yak(char *fluff) { free(fluff); (void) lex(fluff); return (0); } int lex(char *fluff) { free(fluff); return (0); } int main(int argc, char**argv) { char *fluff = malloc(1); printf("fluff: %0x\n",fluff); (void) yak(fluff); return (0); }> 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)?Not at the moment, but a "watchpoint" provider has been bandied about. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development