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 <[EMAIL PROTECTED] >>> >> 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: [EMAIL PROTECTED] > IT Department: +41 (0)43 288 40 54 > Main phone: +41 (0)43 288 40 50 > > > > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss@opensolaris.org Steve Peters [EMAIL PROTECTED] _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
