ustack probably works by building a list of instruction pointers which are later turned into a pretty string which makes this tricky enough that I'm not surprised it doesn't work. That said it would be sweet if it did work by just storing the raw internal ustack representation somehow and allowing it to be optionally traced later.
Some cool use cases malloc/free history, leak diagnostics. I used ustack to implement a ref counting history mechanism that required setting a huge buffer size and using grep to dig the info I wanted out of massive logs of ustack traces. Basically I wanted to find errant add/dec ref operations by logging each one and at some point in the program's execution the ref count goes bad and at that point I want to trace the ref history for just that object. Looking at the ustacks of the add/dec ref operations makes fixing these types of problems trivial. If dtrace let me maintain a data structure of ustacks's keyed by some value that I could later selectively trace that would have been sweet. Sounds like I'm not the only one who could use that. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of > Vladimir Marek > Sent: Friday, February 22, 2008 8:42 AM > To: LiJIan > Cc: [email protected] > Subject: Re: [dtrace-discuss] How to save ustack result into > a map, or pass it to another program > > > I want to save the stack information when memory is allocated using > > following script, but it doesn't work. Could anyone help me > with it ? > > > ######### > > pid$1::malloc_internal:return, > > pid$1::oversize:entry > > /self->size/ > > { > > allocateMem[arg1] = ustack(10); /* save relationship > <address, stack> */ > > self->size = 0; > > } > > Wouldn't be enough to just > ... > { > trace(arg1); > ustack(10); > } > > and redirect the output to a file? I don't believe that you > can assign ustack's output to any internal variable. > > Other possibility would be to use > ... > { > @[arg1,ustack(10)]=count(); > } > > This would run until you press Ctrl-c, and then print out all > combinations of arg1,ustack(10) tuple, with the count of how > many times this combination happened. > > I'm not sure if I can describe it well, here is example: > > ============================================================== > ========== > dtrace -n '*write:[EMAIL PROTECTED],stack()]=count()}' > ... > Ctrl+C > > ... > 1 > genunix`write32+0x1e > stackC genunix`dtrace_systrace_syscall32+0x119 > unix`sys_syscall32+0x101 > 50 > 0 > genunix`write+0x2af > genunix`write32+0x1e > stackB genunix`dtrace_systrace_syscall32+0x119 > unix`sys_syscall32+0x101 > 57 > 0 > genunix`fop_write+0x69 > genunix`write+0x2af > stackA genunix`write32+0x1e > genunix`dtrace_systrace_syscall32+0x119 > unix`sys_syscall32+0x101 > 57 > ============================================================== > ========== > I added the stackA,B,C notes to this output. > > If you read the result from the bottom upwards, you will see > that write was called from stackA and returned 0 57times. > write was called using call path stackB and returned 0 > 57times. etc ... > > > > > I also tried invoking another command to save ustack, using > following scripte but also fail. > > > > ######### > > pid$1::malloc_internal:return, > > pid$1::oversize:entry > > /self->size/ > > { > > system(saveStack(arg1, ustack(10))); /* invoke another > command to save stack*/ > > self->size = 0; > > } > > You can't run external programs like that. You have to use > system(...). > Look at > http://wikis.sun.com/display/DTrace/Actions+and+Subroutines#Ac > tionsandSubroutines-%7B%7Bsystem%7D%7D > > > > Here saveSatck is an executable program, it save "arg1" and > "stack" in a map. > > I'm afraid that you can't pass ustack() output as an argument either. > > > > I don't want to print out result of ustack on screen, > because the output is very large after long time running. > > Redirect it to file, or use '-o' command line switch (be > aware that '-o file' does not overwrite original file, but > rather appends to it). > > As a side note, maybe there are better tools for what you are > tyring to achieve? For hunting problems with memory Solaris > has libumem. > > man umem_debug > > But that's outside of the scope of this list, I'm afraid. > > -- > Vlad > _______________________________________________ dtrace-discuss mailing list [email protected]
