All,
I've run into what appears to be a bug in the OS X port of libdtrace.
Take the following script:
---8<--- bad.d ---8<---
#pragma D option switchrate=5000hz
profile-1234hz
/arg1 != NULL && pid == $pid/
{
@[ufunc(arg1)] = count();
}
tick-1sec
{
printa(@);
}
---8<--- bad.d ---8<---
Running that yields the following output on my Mac running 10.6.4:
% sudo ./bad.d
dtrace: script './bad.d' matched 2 probes
CPU ID FUNCTION:NAME
2 155691 :tick-1sec
2 155691 :tick-1sec
libdtrace.dylib`dtrace_aggregate_snap 1
libdtrace.dylib`gethrtime 1
CoreFoundation`CFRetain 1
libSystem.B.dylib`new_sem_from_pool 1
libSystem.B.dylib`_pthread_cond_remove 1
libSystem.B.dylib`__sflush 1
libSystem.B.dylib`fflush 1
libdtrace.dylib`dt_ioctl 2
libSystem.B.dylib`pthread_mutex_lock 2
libSystem.B.dylib`_pthread_cond_wait 2
libSystem.B.dylib`semaphore_timedwait_signal_trap 3
libSystem.B.dylib`__nanotime 3
libSystem.B.dylib`semaphore_wait_trap 4
libdtrace.dylib`dt_consume_cpu 5
libSystem.B.dylib`ioctl 5
libdtrace.dylib`dtrace_consume 6
libSystem.B.dylib`__ioctl 11
2 155691 :tick-1sec
dtrace`0x100003d72 1
libdtrace.dylib`dtrace_aggregate_snap 1
libdtrace.dylib`dtrace_work 1
libdtrace.dylib`gethrtime 1
CoreFoundation`CFRetain 1
CoreSymbolication`NListRangeChecker<SizeAndEndianness<Pointer64,
LittleEndian> >::next() 1
Segmentation fault
%
Steve/James/other Apple folks: do you lurk here? Is there a better vector
for filing bugs of this nature? (I have one other for you around argument
stability.)
Also, let me thank you again for the Mac port -- it's been very useful to
be able to quickly prototype the DTrace-based infrastructure that we're
currently building!
- Bryan
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
