[M3devel] A GC/compiler/Pickle interaction bug

[Dragiša Durić]

  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>