[M3devel] A GC/compiler/Pickle interaction bug

[Rodney M. Bates]

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.

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