Manoj Joseph
2006-Jan-04 11:46 UTC
[dtrace-discuss] Dtrace not picking up the symbols for user stack.
Hi, I was trying to get the user stack from a probe. Like this: bash-3.00# dtrace -n ''fbt:zfs:zfs_getsecattr:{ustack(); exit(0);}'' dtrace: description ''fbt:zfs:zfs_getsecattr:'' matched 2 probes CPU ID FUNCTION:NAME 0 37508 zfs_getsecattr:entry 0xff31d114 0xff384da0 0x13d40 0x12018 0x11200 No symbols! The binary is not stripped. bash-3.00# file /usr/bin/ls /usr/bin/ls: ELF 32-bit MSB executable SPARC Version 1, dynamically linked, not stripped, no debugging information available bash-3.00# /usr/ccs/bin/nm /usr/bin/ls | grep main [142] | 71488| 3132|FUNC |GLOB |0 |9 |main [196] | 155748| 0|FUNC |GLOB |0 |UNDEF |textdomain Why is dtrace not picking up the symbols? I am on snv_30. bash-3.00# uname -a SunOS pdruv2 5.11 snv_30 sun4u sparc SUNW,Sun-Fire-V240 Regards, Manoj
Roch Bourbonnais - Performance Engineering
2006-Jan-04 13:21 UTC
[dtrace-discuss] Dtrace not picking up the symbols for user stack.
This is because the process that triggered the problem has itself exited before your dtrace command tried to translate the addresses into symbols. If you start the triggering command with a -c argument this may solve your issue. dtrace -n ''fbt:zfs:zfs_readdir:{ustack(); exit(0);}'' -c "ls /zfs" ^^^^^^^^^^^^ ... CPU ID FUNCTION:NAME 0 33305 zfs_readdir:entry libc.so.1`getdents64+0x4 ls`rddir+0x58 ls`pdirectory+0xf0 ls`main+0xaa4 ls`_start+0x108 -r Manoj Joseph writes: > Hi, > > I was trying to get the user stack from a probe. Like this: > > bash-3.00# dtrace -n ''fbt:zfs:zfs_getsecattr:{ustack(); exit(0);}'' > dtrace: description ''fbt:zfs:zfs_getsecattr:'' matched 2 probes > CPU ID FUNCTION:NAME > 0 37508 zfs_getsecattr:entry > > 0xff31d114 > 0xff384da0 > 0x13d40 > 0x12018 > 0x11200 > > No symbols! The binary is not stripped. > > bash-3.00# file /usr/bin/ls > /usr/bin/ls: ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, not stripped, no debugging information available > > bash-3.00# /usr/ccs/bin/nm /usr/bin/ls | grep main > [142] | 71488| 3132|FUNC |GLOB |0 |9 |main > [196] | 155748| 0|FUNC |GLOB |0 |UNDEF |textdomain > > Why is dtrace not picking up the symbols? > > I am on snv_30. > bash-3.00# uname -a > SunOS pdruv2 5.11 snv_30 sun4u sparc SUNW,Sun-Fire-V240 > > Regards, > Manoj > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org
Adam Leventhal
2006-Jan-04 16:04 UTC
[dtrace-discuss] Dtrace not picking up the symbols for user stack.
Hi Manoj, The problem is that while the ustack() action grabs the program counter stack at probe time, the program counters are resolved to symbols later when the buffer is snapshotted by the user-land consumer. In addition to using the -c or -p options as Roch suggested, you can also use the stop() action to ensure the process doesn''t exit until the ustack() has been processed as described toward the end of this page: http://docs.sun.com/app/docs/doc/817-6223/6mlkidlmm?a=view Adam On Wed, Jan 04, 2006 at 05:16:58PM +0530, Manoj Joseph wrote:> Hi, > > I was trying to get the user stack from a probe. Like this: > > bash-3.00# dtrace -n ''fbt:zfs:zfs_getsecattr:{ustack(); exit(0);}'' > dtrace: description ''fbt:zfs:zfs_getsecattr:'' matched 2 probes > CPU ID FUNCTION:NAME > 0 37508 zfs_getsecattr:entry > > 0xff31d114 > 0xff384da0 > 0x13d40 > 0x12018 > 0x11200 > > No symbols! The binary is not stripped. > > bash-3.00# file /usr/bin/ls > /usr/bin/ls: ELF 32-bit MSB executable SPARC Version 1, dynamically > linked, not stripped, no debugging information available > > bash-3.00# /usr/ccs/bin/nm /usr/bin/ls | grep main > [142] | 71488| 3132|FUNC |GLOB |0 |9 |main > [196] | 155748| 0|FUNC |GLOB |0 |UNDEF |textdomain > > Why is dtrace not picking up the symbols? > > I am on snv_30. > bash-3.00# uname -a > SunOS pdruv2 5.11 snv_30 sun4u sparc SUNW,Sun-Fire-V240 > > Regards, > Manoj > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl