Displaying system call buffers with dtrace?
Gary Mills
putmsg system call using dtrace. This is on sparc, with the 32-bit
executable and 64-bit kernel. Here's my last try, but it only
complains about a null pointer in the `trace' statement:
struct strbuf {
int maxlen;
int len;
char *buf;
};
self struct strbuf *x;
syscall::putmsg:entry
/pid != $pid/
{
self->x = copyin(arg2, sizeof(struct strbuf));
trace(copyinstr(self->x->buf));
}
What's the proper way to display the buffer? I have read the
400-page manual.
--
-Gary Mills- -Unix Support- -U of M Academic Computing and Networking-
Brendan Gregg
On 18 Mar 2005, Gary Mills wrote:
> I'm attempting to display the contents of the data buffer from the
> putmsg system call using dtrace. This is on sparc, with the 32-bit
> executable and 64-bit kernel. Here's my last try, but it only
> complains about a null pointer in the `trace' statement:
>
> struct strbuf {
> int maxlen;
> int len;
> char *buf;
> };
> self struct strbuf *x;
> syscall::putmsg:entry
> /pid != $pid/
> {
> self->x = copyin(arg2, sizeof(struct strbuf));
> trace(copyinstr(self->x->buf));
> }
>
> What's the proper way to display the buffer? I have read the
> 400-page manual.
Try this,
# dtrace -n 'syscall::putmsg:entry {
trace(copyinstr((uintptr_t)((struct strbuf *)arg2)->buf)); }'
dtrace: description 'syscall::putmsg:entry ' matched 1 probe
CPU ID FUNCTION:NAME
0 153 putmsg:entry Mar 19 19:40:55 ssh[21182]:
[ID 514540 FACILITY_AND_PRIORITY] libpkcs11: No slots presented from
/usr/lib/security/pkcs11_kernel.so. Skipping this plug-in at this time.
I tested it with a few commands like logger, but the message above came
from ssh. Looks like it is asking the Solaris Cryptographic Framework for
a hand at doing encryption?...
Brendan
[Sydney, Australia]
Gary Mills
># dtrace -n 'syscall::putmsg:entry {
> trace(copyinstr((uintptr_t)((struct strbuf *)arg2)->buf)); }'
>dtrace: description 'syscall::putmsg:entry ' matched 1 probe
>CPU ID FUNCTION:NAME
> 0 153 putmsg:entry Mar 19 19:40:55 ssh[21182]:
> [ID 514540 FACILITY_AND_PRIORITY] libpkcs11: No slots presented from
> /usr/lib/security/pkcs11_kernel.so. Skipping this plug-in at this time.
>I tested it with a few commands like logger, but the message above came
>from ssh. Looks like it is asking the Solaris Cryptographic Framework for
>a hand at doing encryption?...
Yes, that's what I was hoping to see! Your D script is cleaner, too.
However, when I try it, I get this:
# dtrace -s /tmp/putmsg.d
dtrace: script '/tmp/putmsg.d' matched 1 probe
dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid address (0x26000) in action #1 at DIF offset 24
...
dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid alignment (0xfd7f9784) in action #1 at DIF offset 24
dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid alignment (0xfd7f969c) in action #1 at DIF offset 24
The alignment errors come from `lp', which is a 32-bit executable.
Casper H.S. Dik
>Yes, that's what I was hoping to see! Your D script is cleaner, too.
>However, when I try it, I get this:
># dtrace -s /tmp/putmsg.d
>dtrace: script '/tmp/putmsg.d' matched 1 probe
>dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid address (0x26000) in action #1 at DIF offset 24
>...
>dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid alignment (0xfd7f9784) in action #1 at DIF offset 24
>dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid alignment (0xfd7f969c) in action #1 at DIF offset 24
>The alignment errors come from `lp', which is a 32-bit executable.
The kernel is 64 bit? Then you need to copy in a 32 bit putmsg structure.
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Gary Mills
>Gary Mills <mi...@mira.cc.umanitoba.ca> writes:
>>Yes, that's what I was hoping to see! Your D script is cleaner, too.
>>However, when I try it, I get this:
>># dtrace -s /tmp/putmsg.d
>>dtrace: script '/tmp/putmsg.d' matched 1 probe
>>dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid address (0x26000) in action #1 at DIF offset 24
>>...
>>dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid alignment (0xfd7f9784) in action #1 at DIF offset 24
>>dtrace: error on enabled probe ID 1 (ID 148: syscall::putmsg:entry): invalid alignment (0xfd7f969c) in action #1 at DIF offset 24
>>The alignment errors come from `lp', which is a 32-bit executable.
>The kernel is 64 bit? Then you need to copy in a 32 bit putmsg structure.
Dtrace is messy when the pointers are different lengths. I got this
to work, although I'm not that happy with my solution. I'm debugging
a problem with the `lp' command on one Solaris 10 machine.
`./putmsg.d lp' does display all of lp's syslog messages. Here's
my script:
#!/usr/sbin/dtrace -s
struct strbuf32 {
int maxlen;
int len;
int buf;
};
syscall::putmsg:entry
/arg2 != 0 && execname == $$1/
{
self->s = (struct strbuf32 *)copyin((uintptr_t)((struct strbuf32 *)arg2),
sizeof(struct strbuf32));
/* printf("s: %x, len: %u, buf %x\n",
(uintptr_t)self->s, self->s->len, (uintptr_t)self->s->buf); */
self->b = copyin((uintptr_t)self->s->buf, self->s->len);
trace(stringof(self->b));