[M3devel] A GC/compiler/Pickle interaction bug

Tony Hosking hosking at cs.purdue.edu
Sun Apr 22 21:22:11 CEST 2007


Yes, this fix is in CVS head.


On Apr 22, 2007, at 3:29 AM, Dragiša Durić wrote:

> It looks like this fix never came through... With cvs-head CM3,
> unpickling of TextRefTbl.T instance still does not work.
>
> dd
>
> On Tue, 2007-01-09 at 13:06 -0500, Tony Hosking wrote:
>> Rodney,
>>
>> I've checked in fixes to RTTypeMap and clients that should restore
>> functional pickling support.  For some reason my commit messages are
>> awaiting moderator approval (it seems my commit id is not the same as
>> my subscription to the m3commit list) before they can be sent out.
>> Please make sure that unpickling now works for you.
>>
>> Best regards,
>>
>> Tony
>>
>> 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.
>>>
>>> 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    /
>>
>>
>>
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> https://mail.elegosoft.com/cgi-bin/mailman/listinfo/m3devel
> -- 
> Dragiša Durić <dragisha at m3w.org>




More information about the M3devel mailing list