[M3devel] A GC/compiler/Pickle interaction bug

[Tony Hosking]

Just grab CVS from before 2007/03/2007 (when I broke GC).  The  
pertinent fix was to RTTypeMap.m3, as at the current CVS head, which  
is dated 2007/01/09.

Thread/GC-related fixes are coming -- I know what the problem is but  
am in the middle of refactoring the heap allocation code.

On May 2, 2007, at 1:45 AM, Dragiša Durić wrote:

>   Is it possible to get this fix separatelly from threading fixes?  
> It's
> more important, esp since only program that crashes threading is
> TestThreads :)
>
>   TIA,
>   dd
>
> On Sun, 2007-04-22 at 15:22 -0400, Tony Hosking wrote:
>> 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>
>>
> -- 
> Dragiša Durić <dragisha at m3w.org>