Re: [boost] serialization - request for formal review

From: Robert Ramey (ramey_at_[hidden])
Date: 2002-07-15 01:04:16

Date: Thu, 4 Jul 2002 11:00:43 +0500
From: "Vahan Margaryan" <vahan_at_[hidden]>
To: <boost_at_[hidden]>
Subject: Re: [boost] serialization - request for formal review
Hello Robert,

----- Original Message -----
From: "Robert Ramey" <ramey_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 02, 2002 8:39 PM
Subject: RE: [boost] serialization - request for formal review

>
> The function delete_created_pointers deletes the created pointers AND
restores
> the original contents of the pointer that was assigned to.  This
effectivily restores
> pointer elements to their original state what ever that may be.  I =
don't
have your
> example, so I can't comment on your particular case.  So, if the =
object
one is trying
> to restore contains unassigned pointers and load invokes an exception, =
and
> delete_created_pointers is called, the pointers will be restored to =
their
original
> unassigned state.  This may cause problems somewhere else but cannot =
be
> addressed from the serialization module.  I believe that
> deleting created pointers AND restoring the original values of the =
changed
> pointer values will effectively address all of these issues.

It looks like two replies (to me and Kostya Altukhov) got mixed into a
single message. Anyway, I'll reply to my part :)

I really hadn't noticed that you were restoring the values of pointers.
However, I don't think that solves the problem. The solution assumes
something about the pointer variable by which loading is performed. =
Consider
this loading code:

//loading code of class C that has member variable a_ of type A*.
   A* a;
   archive >> a;
   a_ =3D a;

If later a crash occurs, the system will attempt to modify the value of =
the
_local variable_ a (causing undefined behavior), whereas the a_ will =
remain
the same and will cause a double deletion fault. This is a serious
limitation on the system for the following reasons:

1. a_ might be a const A*. This prevents me from directly saying archive =
>>
a_, so I have to use this practice. This is a very typical case.

2. You will have problems implementing container persistence. Actually, =
the
function that implements loading of vectors in your library uses code =
very
similar to the above:

T t; // when T =3D A*,
archive >> t;
c.push_back(t).

In particular, I believe this was the reason of the crash
delete_created_pointers( ) in my case (note that the crash occurs inside
this function).

3. For vector, you may be able to fix it. For containers such as set, =
you
can't, restoration of pointer values will crash them.

Below is the test I use.

Regards,
-Vahan

Vahan,

First of all I have to say how much I appreciate the effort you've expended in
you examination of the serialization library.  Your long email and code example
raises subtle and difficult issues that require a lot effort to understand and explain.

Second, I have to concede that I under-estimated the effort its going to take to
address exception recovery in thorough manner.  It never occured to me before
your email of 22 may?  This was probably due to the fact that none of the other
serialization systems I looked at (MFC, Common C++, etc) ever considered
this issue as well as natural intellectual sloth on my part.

After you raised the issue, I spent sometime considering and came up
with my "magic bullet" - keeping track of newly created items and
the previous contents of the memory locations that hold pointers.  Your
analysis above demonstrates beyond question,  that there can be no such "magic bullet".
Restoration of previous contents of locations that hold pointers will be removed.
(I was very suspicious when I had to use reinterpret cast to make it work)
I havn't decided yet whether "delete_created_pointers" stays or goes.

I do agree you with you that the problem revolves around the usage between
pointers as handles controled storage and pointers as references to related
data structures.  In my test and examples,  I didn't mix the two.  A