[M3devel] netobj bug report

[mika at async.caltech.edu]

The code in CM3 is the same.

I am 95% certain this is a bug.  The logic just doesn't make sense.

All you should have to do to reproduce it is the following:

instantiate a subtype of NetObj.T without exporting it.  Then try
to Pickle it.  Your program I think will crash (for no good reason).
Your program I think will not crash if you do export it.

The logic is checking for a surrogate and crashing if you attempt to 
pickle one:

>          IF NOT ISTYPE(x.r, Transport.Location) THEN
>            (* This will gratuitously pickle the ExportInfo ref
>               embedded in x.r.  It would be better to exclude this
>               if and when possible, but it shouldn't hurt for now. *)
>            Pickle.Special.write(self, r, writer);
>          ELSE
>            RAISE Pickle.Error("Can't pickle a surrogate object");
>          END;

The problem is that x.r is only non-NIL once you export the object.
For a new object that has not been exported, x.r is NIL.  Therefore
it is of type Transport.Location and appears to be a surrogate, even
though it is not a surrogate.  The test should be IF x.r = NIL OR NOT ISTYPE...


     Mika

"Coleburn, Randy" writes:
>Hi Mika:
>
>I'm deep in the middle of some other stuff, but read your post with interes=
>t because I've done a LOT of work with both Pickles and Network Objects.
>
>On the surface, I'm not sure whether this is a bug or not.  I've never enco=
>untered this problem before.  But, my brain is in left-field right now with=
> all else I have going on.
>
>I know that I always used the Pickle2 (2nd generation of pickles) to get ar=
>ound some problems with the first generation.  I never used PM3, just CM3 a=
>nd the original "SRC-Systems Research Center" versions.
>
>I know you can also write and register special "pickler" procedures for any=
> particular object to get around problems with the default pickling procedu=
>res (read/write).  I've had to do this on occasion both to resolve problems=
> and to increase performance.  I can provide examples if you need them.
>
>--Randy
>
>Randy C. Coleburn, CISSP-ISSEP, GCED
>Corporate Information Security Officer (CISO)
>Scientific Research Corporation
>
>-----Original Message-----
>From: mika at async.caltech.edu [mailto:mika at async.caltech.edu]=20
>Sent: Thursday, June 27, 2013 7:01 PM
>To: m3devel at elegosoft.com
>Subject: EXT:[M3devel] netobj bug report
>
>Hi m3devel,
>
>I think I found a bug in the Network Objects code.
>
>Here is what I was doing: I made an object that I wanted to export using Ne=
>twork Objects, but I *also* wanted to Pickle the object locally (for persis=
>tence).
>
>I find that if I create the object and try to pickle it, I get a Pickle err=
>or "Can't pickle a surrogate object". =20
>
>The source of the error is in StubLib.m3, the Pickle special that is record=
>ed for network objects:
>
>PROCEDURE OutSpecial(self: Pickle.Special;
>                 r: REFANY;
>                 writer: Pickle.Writer)
>  RAISES  {Pickle.Error, Wr.Failure, Thread.Alerted} =3D
>  BEGIN
>    TYPECASE writer OF
>    | SpecWr(wtr) =3D> OutRef(wtr.c, r);
>    ELSE
>      TYPECASE r OF
>      | NetObj.T(x) =3D>
>          IF NOT ISTYPE(x.r, Transport.Location) THEN
>            (* This will gratuitously pickle the ExportInfo ref
>               embedded in x.r.  It would be better to exclude this
>               if and when possible, but it shouldn't hurt for now. *)
>            Pickle.Special.write(self, r, writer);
>          ELSE
>            RAISE Pickle.Error("Can't pickle a surrogate object");
>          END;
>      ELSE RAISE Pickle.Error("Can't Pickle Rd.T or Wr.T");
>      END;
>    END;
>  END OutSpecial;
>
>(In CM3, OutSpecial2 has the same bug for Pickle2 pickles.  PM3 doesn't hav=
>e Pickle2 nor OutSpecial2.)
>
>The problem is the test
>
>         IF NOT ISTYPE(x.r, Transport.Location) THEN
>            (* This will gratuitously pickle the ExportInfo ref
>               embedded in x.r.  It would be better to exclude this
>               if and when possible, but it shouldn't hurt for now. *)
>            Pickle.Special.write(self, r, writer);
>          ELSE
>            RAISE Pickle.Error("Can't pickle a surrogate object");
>          END;
>
>The intent, I think, is that an object that is remote (that is, has x.r of =
>type Transport.Location) should not be pickle-able.
>
>The problem is that x.r is initially NIL, and NIL is a member of Transport.=
>Location.
>
>My workaround is to FIRST export the object before attempting to Pickle it.=
>  This works fine but it shouldn't be necessary, should it?  What if I don'=
>t want to export the object, but just pickle it?
>
>I believe the test should be changed to be
>
>IF x.r =3D NIL OR NOT ISTYPE(x.r, Transport.Location) THEN...
>
>    Mika
>