[M3devel] A GC/compiler/Pickle interaction bug

[Tony Hosking]

On Dec 30, 2006, at 7:41 PM, Rodney M. Bates wrote:

> I tracked down a bug unpickling to the following.  When executing
> in ConvertPacking.Read, at ConvertPacking.m3:327, this code:
>
>                 WITH ref = LOOPHOLE(dest, UNTRACED REF REFANY) DO
>                   ref^ := v.readRef(nelem.refType);
>                 END;
>
> has a compiler-generated call on RTCollector.CheckStoreTraced(ref).
> CheckStoreTraced expects ref to be a normal reference to an object,
> computes the address of its header (4 bytes less), and sets the  
> dirty bit.
>
> But ConvertPacking is reading in to a field of a recently created
> object that is not first in the object.  It computes ref to point
> to the field, and CheckStoreTraced actually steps on the previous
> real field instead of the header.
>
> It looks like the actions of CheckStoreTraced are needed, but I
> don't right off hand see how to recode Convert to fix this.  It's
> use of ref can't be moved.  Presumably, there could be other unsafe
> code elsewhere using the same technique to store data.

Is CheckStoreTraced strictly needed in this case.  According to the  
language definition, storing a REFANY through an untraced reference  
can hide the reference from the garbage collector:

>> If u is an untraced reference to a traced variable t, then the  
>> validity of the traced references in t is implementation- 
>> dependent, since the garbage collector probably will not trace  
>> them through u.

Thus, one should not expect CheckStoreTraced to be invoked in this  
case.  If u aliases traced storage (even though u itself is untraced,  
which can only occur in UNSAFE code) we should arrange to dirty the  
traced storage via its tidy reference, using an explicit call to  
RTHooks.CheckStoreTraced, passing the tidy reference to the traced  
storage as argument.

>
>
> Does the compiler need a different criterion on when to generate
> the call on CheckStoreTraced?  ref is an UNTRACED REF here, but it
> still is pointing inside a traced object.   Maybe people who modify
> objects in this way need to explicitly call CheckStoreTraced?
>
> -- 
> -------------------------------------------------------------
> Rodney M. Bates, retired assistant professor
> Dept. of Computer Science, Wichita State University
> Wichita, KS 67260-0083
> 316-978-3922
> rodney.bates at wichita.edu
> _______________________________________________
> M3devel mailing list
> M3devel at elegosoft.com
> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel

Antony Hosking                | Associate Professor
Dept of Computer Science      | Office: +1 765 494-6001
Purdue University             | Mobile: +1 765 427-5484
250 N. University Street      | Email:  hosking at cs.purdue.edu
West Lafayette, IN 47907-2066 | http://www.cs.purdue.edu/~hosking
  _--_|\
/      \
\_.--._/    )
       v    /