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 [email protected]
