On Thu, Sep 15, 2005 at 10:23:48PM +0000, Sean Sprague wrote:> Hello list, > > I am a DTrace noob, sadly - I should have done much more > sooner :-( But I am trying to make up ground fast :-) > > I just attended a cracking DTrace seminar by Jonathan > Haslam, and have been inspired to try out some completely > simple D scripts. I have come across a two "problems" (?) > that, in my noobiness, have confused me. > > The shell (with embedded D) script that I have is no more > simple than: > > #!/usr/sbin/dtrace -ws > > syscall::open:entry > /copyinstr(arg0)=="/etc/passwd"/ > { > printf ("No peeking!\n"); > raise (SIGABRT); > } > > I realise that this is flawed bcoz I forgot that normal > shell access to this file would be thru open64(). I will > come back to that. > > So onto confusion 1... > > So I run the script, and in another window, try to cat > /etc/passwd. The cat works (bcoz of the open64() bit) and no > probes fire. So I resort to my trusty old chum truss, and > when I try "truss cat /etc/passwd" (no other truss options > required), the window which is running my D script reports: > > dtrace: error on enabled probe ID 1 (ID 15: > syscall::open:entry): invalid address (0xff354000) in > predicate at DIF offset 28 > > This looks like a bug? Is there a problem here with > DTrace-truss interaction?No; the problem is that dtrace cannot access user pages which have not been faulted in. Generally, you solve this by recording the argument in a thread-local variable, and acting on it in the :return probe: --- cut here --- syscall::open:entry { self->arg = arg0; } syscall::open:return /self->arg != 0 && copyinstr(self->arg) == "/etc/passwd"/ { printf("No peeking!\n"); raise(SIGABRT); } syscall::open:return { self->arg = 0; /* clean up */ } --- cut here --- This is probably happening because truss(1M) does an open("some_static_string", ...) where "some_static_string" hasn''t been otherwise accessed.> Now onto confusion 2..... > > Slightly different D script; but essentially the same: > > #!/usr/sbin/dtrace -ws > > syscall::open*:entry > /copyinstr(arg0)=="/etc/passwd"/ > { > printf ("No peeking!\n"); > raise (SIGABRT); > } > > Now using "open*" to catch open() and open64(). Two probes > are matched correctly when the script runs. > > Now when, in another window, if I cat /etc/passwd, I get the > expected SIGABRT. If I try the truss of the cat again, the > probe fires correctly, but I still get the DTrace error as > above. If I try to open a new terminal window thru > Gnome/JDS, I get two dtrace errors: > > dtrace: error on enabled probe ID 1 (ID 396: > syscall::open64:entry): invalid address (0xfd0ae000) in > predicate at DIF offset 28 > dtrace: error on enabled probe ID 1 (ID 396: > syscall::open64:entry): invalid address (0xff2d4000) in > predicate at DIF offset 28 > > The probes do not fire, and the terminal window is opened. > > Now it gets a bit more strange: with the D script running, > doing a cat/sum/dd of /etc/passwd in another window > generates abort - core dumped in both Bourne shell and Korn > shell; and the shell remains intact. However, if I simply do > "< /etc/passwd", in another window, if it is a Bourne shell > window, the shell remains intact; but if it is a Korn shell, > the shell dies. Erk.This is due to how these are handled; in sh(1), "< /etc/passwd" forks a subshell to do the open; ksh(1) does not.> I have also received: > > dtrace: error on enabled probe ID 2 (ID 14: > syscall::open:entry): invalid address (0xff324000) in > predicate at DIF offset 28 > dtrace: error on enabled probe ID 2 (ID 14: > syscall::open:entry): invalid address (0xe8000) in predicate > at DIF offset 28 > > without any prompting whatsoever.....Those are from other processes on the system doing open()s of static strings; since dtrace(1M) is global, anything doing so will trigger the error probes. Cheers, - jonathan -- Jonathan Adams, Solaris Kernel Development
Hey Sean, On Thu, Sep 15, 2005 at 10:23:48PM +0000, Sean Sprague wrote:> I am a DTrace noob, sadly - I should have done much more > sooner :-( But I am trying to make up ground fast :-)It''s never too late.> So onto confusion 1... > > So I run the script, and in another window, try to cat > /etc/passwd. The cat works (bcoz of the open64() bit) and no > probes fire. So I resort to my trusty old chum truss, and > when I try "truss cat /etc/passwd" (no other truss options > required), the window which is running my D script reports: > > dtrace: error on enabled probe ID 1 (ID 15: > syscall::open:entry): invalid address (0xff354000) in > predicate at DIF offset 28 > > This looks like a bug? Is there a problem here with > DTrace-truss interaction?This is because you''re doing a copyinstr from a memory address which has not yet been faulted in. This is known as a "first touch" fault, and is described in the Solaris Dynamic Tracing Guide. See the section on ''Avoiding Errors'' in chapter 33 User Process Tracing: http://docs.sun.com/app/docs/doc/817-6223/6mlkidlmd?a=view> Now onto confusion 2..... > > Now it gets a bit more strange: with the D script running, > doing a cat/sum/dd of /etc/passwd in another window > generates abort - core dumped in both Bourne shell and Korn > shell; and the shell remains intact. However, if I simply do > "< /etc/passwd", in another window, if it is a Bourne shell > window, the shell remains intact; but if it is a Korn shell, > the shell dies. Erk.If you use the < file redirection syntax, the shell itself will do the open not the spawned process (e.g. cat).> I have also received: > > dtrace: error on enabled probe ID 2 (ID 14: > syscall::open:entry): invalid address (0xff324000) in > predicate at DIF offset 28 > dtrace: error on enabled probe ID 2 (ID 14: > syscall::open:entry): invalid address (0xe8000) in predicate > at DIF offset 28 > > without any prompting whatsoever.....There may be other opens happening on your system which are encountering the same problem as described above. Keep the questions coming! Adam -- Adam Leventhal, Solaris Kernel Development http://blogs.sun.com/ahl
Hello list,
I am a DTrace noob, sadly - I should have done much more
sooner :-( But I am trying to make up ground fast :-)
I just attended a cracking DTrace seminar by Jonathan
Haslam, and have been inspired to try out some completely
simple D scripts. I have come across a two "problems" (?)
that, in my noobiness, have confused me.
The shell (with embedded D) script that I have is no more
simple than:
#!/usr/sbin/dtrace -ws
syscall::open:entry
/copyinstr(arg0)=="/etc/passwd"/
{
printf ("No peeking!\n");
raise (SIGABRT);
}
I realise that this is flawed bcoz I forgot that normal
shell access to this file would be thru open64(). I will
come back to that.
So onto confusion 1...
So I run the script, and in another window, try to cat
/etc/passwd. The cat works (bcoz of the open64() bit) and no
probes fire. So I resort to my trusty old chum truss, and
when I try "truss cat /etc/passwd" (no other truss options
required), the window which is running my D script reports:
dtrace: error on enabled probe ID 1 (ID 15:
syscall::open:entry): invalid address (0xff354000) in
predicate at DIF offset 28
This looks like a bug? Is there a problem here with
DTrace-truss interaction?
Now onto confusion 2.....
Slightly different D script; but essentially the same:
#!/usr/sbin/dtrace -ws
syscall::open*:entry
/copyinstr(arg0)=="/etc/passwd"/
{
printf ("No peeking!\n");
raise (SIGABRT);
}
Now using "open*" to catch open() and open64(). Two probes
are matched correctly when the script runs.
Now when, in another window, if I cat /etc/passwd, I get the
expected SIGABRT. If I try the truss of the cat again, the
probe fires correctly, but I still get the DTrace error as
above. If I try to open a new terminal window thru
Gnome/JDS, I get two dtrace errors:
dtrace: error on enabled probe ID 1 (ID 396:
syscall::open64:entry): invalid address (0xfd0ae000) in
predicate at DIF offset 28
dtrace: error on enabled probe ID 1 (ID 396:
syscall::open64:entry): invalid address (0xff2d4000) in
predicate at DIF offset 28
The probes do not fire, and the terminal window is opened.
Now it gets a bit more strange: with the D script running,
doing a cat/sum/dd of /etc/passwd in another window
generates abort - core dumped in both Bourne shell and Korn
shell; and the shell remains intact. However, if I simply do
"< /etc/passwd", in another window, if it is a Bourne shell
window, the shell remains intact; but if it is a Korn shell,
the shell dies. Erk.
I have also received:
dtrace: error on enabled probe ID 2 (ID 14:
syscall::open:entry): invalid address (0xff324000) in
predicate at DIF offset 28
dtrace: error on enabled probe ID 2 (ID 14:
syscall::open:entry): invalid address (0xe8000) in predicate
at DIF offset 28
without any prompting whatsoever.....
If these are known problems/features, then sincere
apologies, and please forgive the waste of bandwidth.
For reference, the system is an Ultra60, installed with SX
build 20, and then OpenSolaris build 22 built from scratch
and BFU''d on top - actually I lie - the base was SX build
20, then OpenSolaris build 21 built and BFU''d on top, then
OpenSolaris build 22 built from scratch and BFU''d finally on
the top.
Any help gratefully received - even if just to reiterate
that I am a noob, and should go away ;-)
Regards... Sean.
Hey Adam and Jonathan! Thanks so much to you both for the excellent technical explanations, the pointers to the relevant place in the docs, and the very kind words of encouragement. I look forward to our next "meeting" - I am sure/hope it will be soon ;-) Best regards... Sean.