[dtrace-discuss] whatfor.d -- where's null pointer?

[Adam Leventhal]

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
> Oleksandr.Lytvyn at MorganStanley.com
> --------------------------------------------------------
> 
> 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 at opensolaris.org


-- 
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl