Beat Vontobel
2008-Nov-25 14:34 UTC
[dtrace-discuss] Show file descriptors returned by pipe()
Hi dtrace users, even as a dtrace beginner, I was quite successful putting a dtrace script together to help me debug a wierd file descriptor issue on Mac OS X 10.5.5 -- I was able to get all the necessary debugging information from syscalls like open, dup, dup2, fork, write and many more, just with pipe I got no idea on how to output both of the file descriptors returned using dtrace. With pipe being defined as follows int pipe(int *fildes); actually returning the two file descriptors as fildes[0] and fildes[1], I always get fildes[0] in arg0 (and arg1) inside syscall::pipe:return. But where is fildes[1]? I thought I''d probably need to get the pointer and then use copyin() -- but I just can''t figure out how... syscall::pipe:entry { /* Any possibility to get a pointer here already to be assigned to self->something to help me in "return"? */ } syscall::pipe:return { printf("pipe(%d, %d)\n", arg0, arg1 /* <- How to get the second file descriptor? */); } Any help is appreciated! Thanks, Beat
James Carlson
2008-Nov-25 15:07 UTC
[dtrace-discuss] Show file descriptors returned by pipe()
Beat Vontobel writes:> actually returning the two file descriptors as fildes[0] and > fildes[1], I always get fildes[0] in arg0 (and arg1) inside > syscall::pipe:return. But where is fildes[1]? I thought I''d probably > need to get the pointer and then use copyin() -- but I just can''t > figure out how... > > syscall::pipe:entry > { > /* Any possibility to get a pointer here already to be assigned to > self->something to help me in "return"? */You''d ordinarily be on the right sort of path with this: self->filedes = arg0; ... but the syscall provider is weird. It exposes implementation details, such as how arguments are returned for 64-bit kernels. In this case, the two file descriptors are passed back in one argument, so just do something like this: #!/usr/sbin/dtrace -qs - syscall::pipe:return { printf("pipe(%d, %d) in %s\n", arg0 & 0xffffffff, arg0 >> 32, execname); ustack(); } -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Beat Vontobel
2008-Nov-25 15:26 UTC
[dtrace-discuss] Show file descriptors returned by pipe()
Hi James, thanx for your quick reply!> printf("pipe(%d, %d) in %s\n", arg0 & 0xffffffff, arg0 >> 32,Unfortunately, the higher 32 bits are always 0 for me with this approach, even though the lower 32 bits correctly hold the first of the two file descriptors. Did Apple maybe break something when they integrated your code into OS X? :) (I know they broke some other stuff in dtrace, some of it intentionally... :) ) Beat. Am 25.11.2008 um 16:07 schrieb James Carlson:> Beat Vontobel writes: >> actually returning the two file descriptors as fildes[0] and >> fildes[1], I always get fildes[0] in arg0 (and arg1) inside >> syscall::pipe:return. But where is fildes[1]? I thought I''d probably >> need to get the pointer and then use copyin() -- but I just can''t >> figure out how... >> >> syscall::pipe:entry >> { >> /* Any possibility to get a pointer here already to be assigned to >> self->something to help me in "return"? */ > > You''d ordinarily be on the right sort of path with this: > > self->filedes = arg0; > > ... but the syscall provider is weird. It exposes implementation > details, such as how arguments are returned for 64-bit kernels. In > this case, the two file descriptors are passed back in one argument, > so just do something like this: > > #!/usr/sbin/dtrace -qs - > > syscall::pipe:return > { > printf("pipe(%d, %d) in %s\n", arg0 & 0xffffffff, arg0 >> 32, > execname); > ustack(); > } > > -- > James Carlson, Solaris Networking <james.d.carlson at sun.com > > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677 >-- Beat Vontobel, CTO, MeteoNews AG Siewerdtstr. 105, CH-8050 Zurich, Switzerland E-Mail: b.vontobel at meteonews.ch IT Department: +41 (0)43 288 40 54 Main phone: +41 (0)43 288 40 50
James Carlson
2008-Nov-25 15:31 UTC
[dtrace-discuss] Show file descriptors returned by pipe()
Beat Vontobel writes:> Hi James, > > thanx for your quick reply! > > > printf("pipe(%d, %d) in %s\n", arg0 & 0xffffffff, arg0 >> 32, > > Unfortunately, the higher 32 bits are always 0 for me with this > approach, even though the lower 32 bits correctly hold the first of > the two file descriptors.Sounds like a 32-bit kernel. In that case, try using arg0 and arg1.> Did Apple maybe break something when they > integrated your code into OS X? :) (I know they broke some other stuff > in dtrace, some of it intentionally... :) )I don''t think so. The issue here is that syscall itself exposes kernel implementation details, so it''s highly dependent on how your system is put together. Check out: http://wikis.sun.com/display/DTrace/Stability and try this: dtrace -ev -n syscall::pipe:return -- James Carlson, Solaris Networking <james.d.carlson at sun.com> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
Beat Vontobel
2008-Nov-27 17:26 UTC
[dtrace-discuss] Show file descriptors returned by pipe()
Hi James, thx again for the help -- unfortunately I couldn''t figure out how to get at both of the descriptors on OS X. But I solved the original problem the old (and hard) way without DTRACE, so no more urgent help needed on this.> The issue here is that syscall itself exposes> kernel implementation details, so it''s highly dependent on how your > system is put together.> Sounds like a 32-bit kernel. In that case, try using arg0 and arg1.Nope, that''s what I tried first (before knowing about the 64-bit implementation issues). And it is actually a 64-bit kernel. But maybe that''s one of the things that will be fixed with OS X 10.6, when Apple hopefully also cleans up the last standing 32-to-64-bit-transition left-overs, or when this part of the DTRACE interface maybe once stabilizes. Thank you anyway! Beat Am 25.11.2008 um 16:31 schrieb James Carlson:> Beat Vontobel writes: >> Hi James, >> >> thanx for your quick reply! >> >>> printf("pipe(%d, %d) in %s\n", arg0 & 0xffffffff, arg0 >> 32, >> >> Unfortunately, the higher 32 bits are always 0 for me with this >> approach, even though the lower 32 bits correctly hold the first of >> the two file descriptors. > > Sounds like a 32-bit kernel. In that case, try using arg0 and arg1. > >> Did Apple maybe break something when they >> integrated your code into OS X? :) (I know they broke some other >> stuff >> in dtrace, some of it intentionally... :) ) > > I don''t think so. The issue here is that syscall itself exposes > kernel implementation details, so it''s highly dependent on how your > system is put together. > > Check out: > > http://wikis.sun.com/display/DTrace/Stability > > and try this: > > dtrace -ev -n syscall::pipe:return > > -- > James Carlson, Solaris Networking <james.d.carlson at sun.com > > > Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 > 2084 > MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 > 1677 >-- Beat Vontobel, CTO, MeteoNews AG Siewerdtstr. 105, CH-8050 Zurich, Switzerland E-Mail: b.vontobel at meteonews.ch IT Department: +41 (0)43 288 40 54 Main phone: +41 (0)43 288 40 50
Steve Peters
2008-Nov-29 20:15 UTC
[dtrace-discuss] Show file descriptors returned by pipe()
On Nov 27, 2008, at 9:26 AM, Beat Vontobel wrote:> Hi James, > > thx again for the help -- unfortunately I couldn''t figure out how to > get at both of the descriptors on OS X.This is a bug. Please file a bug report. See: <http://developer.apple.com/faq/bugreporting.html> Here''s a workaround: #!/usr/sbin/dtrace -qs - syscall::pipe:return { printf("pipe(%d, %d) in %s\n", arg0 , uthread->uu_rval[1], execname); ustack(); } $ sudo dtrace -C -s /tmp/foo.d cc1: warning: /dev/fd/5 is shorter than expected dtrace: script ''/tmp/foo.d'' matched 1 probe CPU ID FUNCTION:NAME 1 17734 pipe:return pipe(3, 4) in bash libSystem.B.dylib`pipe+0xa bash`0x10001069f bash`0x10001297b bash`0x10000337f bash`0x100002f3c bash`0x100000d78 0x1 ^C SCP> But I solved the original > problem the old (and hard) way without DTRACE, so no more urgent help > needed on this. > >> The issue here is that syscall itself exposes > >> kernel implementation details, so it''s highly dependent on how your >> system is put together. > > >> Sounds like a 32-bit kernel. In that case, try using arg0 and arg1. > > > Nope, that''s what I tried first (before knowing about the 64-bit > implementation issues). And it is actually a 64-bit kernel. But maybe > that''s one of the things that will be fixed with OS X 10.6, when Apple > hopefully also cleans up the last standing 32-to-64-bit-transition > left-overs, or when this part of the DTRACE interface maybe once > stabilizes. > > Thank you anyway! > Beat > > > Am 25.11.2008 um 16:31 schrieb James Carlson: > >> Beat Vontobel writes: >>> Hi James, >>> >>> thanx for your quick reply! >>> >>>> printf("pipe(%d, %d) in %s\n", arg0 & 0xffffffff, arg0 >> 32, >>> >>> Unfortunately, the higher 32 bits are always 0 for me with this >>> approach, even though the lower 32 bits correctly hold the first of >>> the two file descriptors. >> >> Sounds like a 32-bit kernel. In that case, try using arg0 and arg1. >> >>> Did Apple maybe break something when they >>> integrated your code into OS X? :) (I know they broke some other >>> stuff >>> in dtrace, some of it intentionally... :) ) >> >> I don''t think so. The issue here is that syscall itself exposes >> kernel implementation details, so it''s highly dependent on how your >> system is put together. >> >> Check out: >> >> http://wikis.sun.com/display/DTrace/Stability >> >> and try this: >> >> dtrace -ev -n syscall::pipe:return >> >> -- >> James Carlson, Solaris Networking <james.d.carlson at sun.com >>> >> Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 >> 2084 >> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 >> 1677 >> > > > -- > > Beat Vontobel, CTO, MeteoNews AG > > Siewerdtstr. 105, CH-8050 Zurich, Switzerland > > E-Mail: b.vontobel at meteonews.ch > IT Department: +41 (0)43 288 40 54 > Main phone: +41 (0)43 288 40 50 > > > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.orgSteve Peters scp at mac.com