[M3devel] netobj bug report

[Coleburn, Randy]

Hi Mika:

I'm deep in the middle of some other stuff, but read your post with interest 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 encountered 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 around some problems with the first generation.  I never used PM3, just CM3 and 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 procedures (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] 
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 Network Objects, but I *also* wanted to Pickle the object locally (for persistence).

I find that if I create the object and try to pickle it, I get a Pickle error "Can't pickle a surrogate object".  

The source of the error is in StubLib.m3, the Pickle special that is recorded for network objects:

PROCEDURE OutSpecial(self: Pickle.Special;
                 r: REFANY;
                 writer: Pickle.Writer)
  RAISES  {Pickle.Error, Wr.Failure, Thread.Alerted} =
  BEGIN
    TYPECASE writer OF
    | SpecWr(wtr) => OutRef(wtr.c, r);
    ELSE
      TYPECASE r OF
      | NetObj.T(x) =>
          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 have 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 = NIL OR NOT ISTYPE(x.r, Transport.Location) THEN...

    Mika