Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Tue, 2008-04-22 at 11:21 -0700, Adam Leventhal wrote: On Tue, Apr 22, 2008 at 10:57:26AM -0700, Roman Shaposhnik wrote: On Tue, 2008-04-22 at 10:21 -0700, Adam Leventhal wrote: On Tue, Apr 22, 2008 at 09:37:57AM -0400, Lytvyn, Oleksandr (IT) wrote: That's an interesting analysis. Hope we can have a fix soon. I forgot to mention that you can work around the issue by replacing curlwpsinfo-pr_stype with: (((this-tmp = curthread-t_sobj_ops) != NULL) ? this-tmp-sobj_type : 0) Isn't there a race-condition still (although a much less probable one)? I don't think so; can you describe the race condition you see? Without knowing the details of how the structure to which t_sobj_ops is pointing gets managed it seems to me that there's a tiny window of opportunity between recording the address of the structure into this-tmp and the structure itself dealocated/reused for something else. Of course, the recorded address will still be valid, but once you do this-tmp-sobj_type you might get garbage. Can this happen? Thanks, Roman. ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Tue, Apr 22, 2008 at 11:34:32AM -0700, Roman Shaposhnik wrote: Without knowing the details of how the structure to which t_sobj_ops is pointing gets managed it seems to me that there's a tiny window of opportunity between recording the address of the structure into this-tmp and the structure itself dealocated/reused for something else. Of course, the recorded address will still be valid, but once you do this-tmp-sobj_type you might get garbage. Can this happen? No. t_sobj_ops is always assigned the address of a static structure that is never deallocated. But it's a fair point for other cases, and I don't think there's a generic solution. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Apr 21, 2008, at 11:00 AM, Adam Leventhal wrote: 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 Wow, that is a cool bug. If you choose to do some element of optimization, is it possible to guarantee every case will be correctly handled? I worry that it might be difficult to reason about the thread safety of code without explicit guarantees about how this is handled. James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Mon, Apr 21, 2008 at 11:00:29AM -0700, Adam Leventhal wrote: 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: [...] 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. In the world of LISP macros the macro writer would gensym a local variable (probe-local in this case) to deal with this sort of issue. Perhaps the DTrace translator facility needs a probe-local gensym feature. Nico -- ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Mon, Apr 21, 2008 at 01:54:16PM -0500, Nicolas Williams wrote: In the world of LISP macros the macro writer would gensym a local variable (probe-local in this case) to deal with this sort of issue. Perhaps the DTrace translator facility needs a probe-local gensym feature. Indeed, many languages have a construct to let you create a new scope; adding one to D might be a good idea. Adam -- Adam Leventhal, Fishworkshttp://blogs.sun.com/ahl ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
Re: [dtrace-discuss] whatfor.d -- where's null pointer?
On Apr 21, 2008, at 1:04 PM, Adam Leventhal wrote: On Mon, Apr 21, 2008 at 11:45:25AM -0700, James McIlree wrote: 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 If you choose to do some element of optimization, is it possible to guarantee every case will be correctly handled? I worry that it might be difficult to reason about the thread safety of code without explicit guarantees about how this is handled. The optimization would just be to perform the load once -- this is what most C compilers would do absent the volatile keyword. And I absolutely would not trust the C compiler in this case either :-). It's not required by spec to load once and only once, and there are times when it doesn't. James M ___ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
[dtrace-discuss] whatfor.d -- where's null pointer?
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
