Hi!
Tried to ask this on an Dtrace web forum, but apparently that one is not
closely watched by Dtrace Gods :)
The problem is the following. I have a simple program with two threads
constantly locking and unlocking a mutex:
bash-3.00> dtrace -l -n pid8382::mutex_lock:entry
ID PROVIDER MODULE FUNCTION NAME
133670 pid8382 LM1`ld.so.1 lmutex_lock entry
139558 pid8382 libc.so.1 lmutex_lock entry
Now, if I try to use userfunc.d to track what''s going on below
mutex_lock, it doesn''t work:
bash-3.00> ./userfunc.d 8382 mutex_lock
dtrace: script ''./userfunc.d'' matched 13011 probes
And I can wait forever to see anything being called by mutex_lock.
However, if I add module name (libc.so.1) to the probe descriptions
inside userfunc.d, like this (a slightly modified userfunc.d follows):
#!/usr/sbin/dtrace -Fs
pid$1:libc.so.1:$2:entry
{
self->trace = 1;
}
pid$1:::entry,
pid$1:::return
/self->trace/
{
}
pid$1:libc.so.1:$2:return
/self->trace/
{
self->trace = 0;
}
And now suddenly every function called by mutex_lock is revealed:
bash-3.00> ./userfunc.d 8382 mutex_lock | head -10
dtrace: script ''./userfunc.d'' matched 13009 probes
CPU FUNCTION
2 -> mutex_lock
2 -> mutex_lock_impl
2 -> slow_lock
2 -> mutex_trylock_adaptive
2 <- mutex_trylock_adaptive
2 <- slow_lock
2 <- mutex_lock_impl
2 <- mutex_lock
2 -> mutex_lock
So, the question is: what am I missing here? Why does
pid$1::mutex_lock:entry fail to match what
pid$1:libc.so.1:mutex_lock:entry matches?
Regards
Oleksandr Lytvyn
P.S. This is Solaris10 x86
--------------------------------------------------------
NOTICE: If received in error, please destroy and notify sender. Sender does not
intend to waive confidentiality or privilege. Use of this email is prohibited
when received in error.