dtrace discuss - Sep 2009 - "this" variables being overridden?

Hi

I encountered this problem a few times in the past, but only now it is 
consistent enough so I can write this email.  In short, the problem is 
that after I copy some structure from the profiled program to the dtrace 
space, and set a "this-dataP" variable to point to the local copy,
after
a while some of the fields of the local structure are overridden with 
junk values.  In particular, consider the following code:

pid$target::foo:entry
{
  this->dataP = (ProfData*)copyin(arg2, sizeof(ProfData));
}


/* various of other foo:entry clauses with various predicates. 
 * None of them is doing a copyin operation.  
 */

[snip]

pid$target::foo:entry
/disabled[0]==0 && arg1 != 0/
{

  this->ablock = arg0;

  this->time = this->dataP->execTime;
  this->ltime = this->dataP->logTxExecTime;
  this->wtime = this->dataP->confWaitTime;
  this->trials = this->dataP->counters[NumRetries];

  this->confsWonWR   = this->dataP->counters[NumWonWRConf] ? 1:0;
  this->confsWonWRUp = this->dataP->counters[NumWonWRUpConf] ? 1:0;
  this->confsWonRW   = this->dataP->counters[NumWonRWConf] ? 1:0;
  this->confsWonWW   = this->dataP->counters[NumWonWWConf] ? 1:0;

  @txInfo[
    this->ablock,
    this->trials,
    this->time/1000,
    this->ltime/1000,
    this->wtime/1000,
    this->confsWonWR,
    this->confsWonWRUp,
    this->confsWonRW,
    this->confsWonWW] = count();
}


At the end of the run, I noticed that some of the data points in the 
aggregation have junk values in some of their key fields.
If I add another:

  this->dataP = (ProfData*)copyin(arg2, sizeof(ProfData));

in the clause where the aggregation is assigned, then the number of junk 
values is significantly reduced, but does not completely disappear... 
(My understanding is that adding this additional copyin is not 
necessary, as "this" variables should be live until the last code
block
that corresponds to a particular probe firing is done executing.)

Any ideas what is going on?  As said, I noticed this phenomena in a 
number of different scripts --- in all it seems like the more time it 
passes between the copyin and the usage of the data, the more likely 
I''ll see junk values...

Yossi

One update: it turns out that when I put in the additional copyin inside 
the clause that reads the data from this->dataP I don''t see any junk
values (the junk that I saw was due to a bug in the profiled program).  
It is only when the copying and the reading of the data are in different 
clauses, which is still not clear to me, because "this" variables
should
retain their values until the last code block that corresponds to a 
particular probe firing is done executing.

Does anyone know why the additional copyin is requited?

Thanks,
Yossi


Yossi Lev (Sun Labs) wrote:
> Hi
>
> I encountered this problem a few times in the past, but only now it is 
> consistent enough so I can write this email.  In short, the problem is 
> that after I copy some structure from the profiled program to the 
> dtrace space, and set a "this-dataP" variable to point to the
local
> copy, after a while some of the fields of the local structure are 
> overridden with junk values.  In particular, consider the following code:
>
> pid$target::foo:entry
> {
>  this->dataP = (ProfData*)copyin(arg2, sizeof(ProfData));
> }
>
>
> /* various of other foo:entry clauses with various predicates. * None 
> of them is doing a copyin operation.  */
>
> [snip]
>
> pid$target::foo:entry
> /disabled[0]==0 && arg1 != 0/
> {
>
>  this->ablock = arg0;
>
>  this->time = this->dataP->execTime;
>  this->ltime = this->dataP->logTxExecTime;
>  this->wtime = this->dataP->confWaitTime;
>  this->trials = this->dataP->counters[NumRetries];
>
>  this->confsWonWR   = this->dataP->counters[NumWonWRConf] ? 1:0;
>  this->confsWonWRUp = this->dataP->counters[NumWonWRUpConf] ? 1:0;
>  this->confsWonRW   = this->dataP->counters[NumWonRWConf] ? 1:0;
>  this->confsWonWW   = this->dataP->counters[NumWonWWConf] ? 1:0;
>
>  @txInfo[
>    this->ablock,
>    this->trials,
>    this->time/1000,
>    this->ltime/1000,
>    this->wtime/1000,
>    this->confsWonWR,
>    this->confsWonWRUp,
>    this->confsWonRW,
>    this->confsWonWW] = count();
> }
>
>
> At the end of the run, I noticed that some of the data points in the 
> aggregation have junk values in some of their key fields.
> If I add another:
>
>  this->dataP = (ProfData*)copyin(arg2, sizeof(ProfData));
>
> in the clause where the aggregation is assigned, then the number of 
> junk values is significantly reduced, but does not completely 
> disappear... (My understanding is that adding this additional copyin 
> is not necessary, as "this" variables should be live until the
last
> code block that corresponds to a particular probe firing is done 
> executing.)
>
> Any ideas what is going on?  As said, I noticed this phenomena in a 
> number of different scripts --- in all it seems like the more time it 
> passes between the copyin and the usage of the data, the more likely 
> I''ll see junk values...
>
> Yossi
>

The extra copyin is required as copyin returns scratch memory and scratch memory
so is only valid in that clause.

--chris
-- 
This message posted from opensolaris.org

Oh, I see, Thanks.  Can I then copy all the data that I need from the 
copied structure into "this" variables in the clause where copyin is 
called, and then use the values in subsequent clauses (that correspond 
to the same probe)? e.g.:

pid$target::foo:entry
{
 this->dataP = (ProfData*)copyin(arg2, sizeof(ProfData));

 this->ablock = arg0;
 this->time = this->dataP->execTime;
}

pid$target::foo:entry
/this->time > 100/
{
 @longTx[this->ablock] = count();
}


The reason I''m asking is that sometimes you would like to use the read 
data in a predicate, and you cannot access the read data before 
executing the copyin...

Thanks,
Yossi



Chris Gerhard wrote:
> The extra copyin is required as copyin returns scratch memory and scratch
memory so is only valid in that clause.
>
> --chris
>

you can do

pid$target::foo:entry
/ (this->dataP = (ProfData*)copyin(arg2, sizeof(ProfData))->execTime >
100/
{
@longTx[arg0] = count();
} 

--chris
-- 
This message posted from opensolaris.org

> Oh, I see, Thanks.  Can I then copy all the data that I need from the
> copied structure into "this" variables in the clause where copyin
is
> called, and then use the values in subsequent clauses (that correspond
> to the same probe)? e.g.:
> 
Yes.

Chip