Hi Thomas,

That's absolutely correct. ustack() is an action() which records data to
trace buffer. A long-standing RFE is to treat it like some more easily
manipulated object, but that hasn't really gained any momentum.

Adam

On Feb 22, 2008, at 11:23 AM, Thomas Reilly wrote:

>
> 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]


--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

_______________________________________________
dtrace-discuss mailing list
[email protected]

Reply via email to