I wrote a simple c programme and do some dtrace test. the progromme shows below(write.c): /////////////////////////////// #include<stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> char *value="hello,my name is wanjm\n"; void main() { int fd; fd=open("/export/home/wanjm/temp/read.txt",O_RDWR|O_CREAT); while(1) { sleep(1); write(fd,value,strlen(value)); } } //////////////////////////////////////// and the dtrace script (write.d) is: syscall::write:entry, fbt::write:entry, pid$1::write:entry, pid$1::write:return, pid$1::_write:entry /pid==$1/ { printf("%s:%s:%s:%s\n",probeprov,probemod,probefunc,probename); stack(100); ustack(100); } /////////////////////////////// when runs the script, the result is : pid17632:libc.so.1:write:entry libc.so.1`write a.out`main+0x43 a.out`_start+0x7a pid17632:libc.so.1:_write:entry [b] libc.so.1`_write [u]libc.so.1`write+0x75[/u][/b] a.out`main+0x43 a.out`_start+0x7a syscall::write:entry unix`sys_sysenter+0x101 [b] libc.so.1`_write+0x15 a.out`main+0x43[/b] a.out`_start+0x7a fbt:genunix:write:entry genunix`dtrace_systrace_syscall+0xb9 unix`sys_sysenter+0x101 libc.so.1`_write+0x15 [u]a.out`main+0x43[/u] a.out`_start+0x7a pid17632:libc.so.1:write:return libc.so.1`write+0x90 a.out`_start+0x7a when syscall probe fires ,why does the stack information lost [u]libc.so.1`write+0x75[/u] and when pid17632:libc.so.1:write:return fires?the main function was lost me. could you please me the reason. -- This message posted from opensolaris.org
Adam Leventhal
2007-Dec-29 18:46 UTC
[dtrace-discuss] why was some stack information lost.
On Fri, Dec 28, 2007 at 07:10:26PM -0800, wan_jm wrote:> when syscall probe fires, why does the stack information lost [u]libc.so.1`write+0x75[/u]In _write, we don''t push a stack frame: libc.so.1`_write: movl $0x4,%eax libc.so.1`_write+5: syscall libc.so.1`_write+7: jae +0xa <libc.so.1`_write+0x13> libc.so.1`_write+9: cmpl $0x5b,%eax libc.so.1`_write+0xc: je -0xe <libc.so.1`_write> libc.so.1`_write+0xe: jmp -0x81df3 <libc.so.1`__cerror> libc.so.1`_write+0x13: ret Because of this, a stack trace will omit what is logically the previous frame -- in effect, _write is executing out of write''s frame. We catch this in pid provider entry probes because of a specific hack to account for the fact that at the entry probe the function won''t have pushed a new stack frame. We don''t have the necessarily semantic information from the syscall probe at to do something similar.> and when pid17632:libc.so.1:write:return fires?the main function was lost me.This is a filed bug: 6551219 ustack from pid return probe omits previous frame We''re implement a hack similar to what we do for pid provider entry probes. - ahl -- Adam Leventhal, FishWorks http://blogs.sun.com/ahl