Hi Oleksandr,
This turned out to be a rather interesting problem. To investigate, I used
this script:
---8<---
off-cpu
{
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
this->tmp = curlwpsinfo->pr_stype;
}
ERROR
{
@[arg2] = count();
}
---8<---
Which resulted in a table like this:
9 1
10 1
5 2
7 2
1 3
3 3
2 5
6 5
4 10
So curlwpsinfo->pr_stype can work and later fail. Looking at the translator
for that field we see that it looks like this:
pr_stype = T->t_sobj_ops ? T->t_sobj_ops->sobj_type : 0;
This compiles to this DIF code:
OFF OPCODE INSTRUCTION
00: 29010001 ldgs DT_VAR(256), %r1 ! DT_VAR(256) = "curthread"
01: 25000002 setx DT_INTEGER[0], %r2 ! 0x0
02: 04010201 sll %r1, %r2, %r1
03: 05010201 srl %r1, %r2, %r1
04: 0e010002 mov %r1, %r2
05: 25000103 setx DT_INTEGER[1], %r3 ! 0x88
06: 07020302 add %r2, %r3, %r2
07: 22020002 ldx [%r2], %r2
08: 10020000 tst %r2
09: 12000011 be 17
10: 0e010002 mov %r1, %r2
11: 25000103 setx DT_INTEGER[1], %r3 ! 0x88
12: 07020302 add %r2, %r3, %r2
13: 22020002 ldx [%r2], %r2
14: 1e020002 ldsw [%r2], %r2
15: 0e020002 mov %r2, %r2
16: 11000012 ba 18
17: 25000002 setx DT_INTEGER[0], %r2 ! 0x0
18: 25000203 setx DT_INTEGER[2], %r3 ! 0x38
19: 04020302 sll %r2, %r3, %r2
20: 2e020302 sra %r2, %r3, %r2
21: 23000002 ret %r2
We can see that we load the t_sobj_ops member once at offset 07 and then again
at offset 17 (right before we load sobj_type at offset 18). The t_sobj_ops
member can be set to NULL asynchronously from other threads so this double
load introduces a window for the failure that you're seeing.
Either we need to use some temporary, probe-local variable (one that can't
conflict with a user-defined variable), or we need to perform some element of
optimization to the generated DIF.
I've filed this bug:
6691541 curlwpsinfo->pr_stype races
Adam
On Fri, Apr 18, 2008 at 04:20:31PM -0400, Lytvyn, Oleksandr (IT) wrote:
> Hi!
>
> Anyone seen this? This one buffles me: I run whatfor.d from
> /usr/demo/dtrace, and here's what I get:
>
> dtrace: script '/usr/demo/dtrace/whatfor.d' matched 12 probes
> dtrace: error on enabled probe ID 1 (ID 681: sched:unix:resume:off-cpu):
> invalid address (0x0) in action #1 at DIF offset 56
> dtrace: error on enabled probe ID 1 (ID 681: sched:unix:resume:off-cpu):
> invalid address (0x0) in action #1 at DIF offset 56
> dtrace: error on enabled probe ID 1 (ID 681: sched:unix:resume:off-cpu):
> invalid address (0x0) in action #1 at DIF offset 56
> dtrace: error on enabled probe ID 1 (ID 681: sched:unix:resume:off-cpu):
> invalid address (0x0) in action #1 at DIF offset 56
> ...
>
> Multitudes of those. Apparently, action #1 of probe ID 1 is:
>
> self->sobj = curlwpsinfo->pr_stype;
>
> So, which address is invalid here? The curlwpsinfo is used in predicate,
> so it cannot be 0x0, because it'd complain about the predicate too. And
> pr_stype is supposed to be char.
>
> What's wrong here?
>
> Found another error report like that on the web, BTW (in German,
> accidentially). But no responses there, unfortunately.
>
> Thanks,
>
> Oleksandr Lytvyn
> Morgan Stanley | Technology
> 210 Carnegie Center, 4th Floor | Princeton, NJ 08540
> Phone: +1 609 936-4026
> Mobile: +1 732 773-4145
> [EMAIL PROTECTED]
> --------------------------------------------------------
>
> 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.
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss@opensolaris.org
--
Adam Leventhal, Fishworks http://blogs.sun.com/ahl
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
