C++ Boost

Serialization

Exception Safety
The process of loading an archive may result in the creation of new objects. That same process may throw an exception at some point. In order to prevent memory leaks and invalid pointers, these situations must be considered. Unfortunately, there is no simple universal solution to this problem. The manner of addressing this must depend on the design of the data structures to be serialized. Below, we discuss varying scenarios in increasing order of difficulty. This discussion presumes that the class member functions are exception safe before considering serialization. That is, the destructor could be called at anytime without referencing an invalid pointer, or creating a memory leak.

  1. class contains no pointers

    No problem here.

  2. class contains only owned pointers

    From here on, we have to make a distinction between pointers used to manage heap storage (owned pointers) and pointers used to refer to related objects (referenced pointers). Programs containing owned pointers must contain code for deleting these objects and returning the deallocated storage to the heap. Programs containing referenced pointers must be designed to ensure that no such referenced pointers are de-referenced after the object pointed to has been destroyed and its storage returned to the heap. If a pointer is stored in only one place, it must be an owned pointer.

    The load function traps any exceptions that occur between the time an object is created and its pointer is stored. Should an exception occur while reading an archive, the created object is deleted and the de-serialized pointer is set to NULL. This ensures that there are no memory leaks. The fact that there are no other copies of this pointer ensures that no pointers are left invalid. The object's destructor should be able to delete any other existing objects in the normal manner without problem. test_delete_pointer.cpp illustrates this case.

  3. class contains one or more referenced pointers

    This situation can be further subdivided into two cases

    1. owned pointers are always serialized before referenced pointers

      Object tracking will ensure that no new objects will be created by the loading of a referenced pointer. If an exception occurs, referenced pointers will not need to be deleted so there will be no memory leaks. The destructor of this class won't attempt to delete these pointers so there will be no problem with dangling references. owned pointers are handled exactly as described above.

    2. class contains referenced pointers which might be created by load

      If a referenced pointer is loaded before its corresponding owned pointer, the object will be allocated on the heap. In certain cases it cannot be known which pointers were created by their owners and which were created by the load function. To address this:
      • Trap exceptions with a try/catch block.
      • Within the catch part, invoke the archive function delete_created_pointers() to delete any pointers created by the class load. Without out other action, objects created in this way would end up as memory leaks as they are not considered owned pointers and hence aren't destroyed.
      • The object's destructor won't try to delete referenced pointers so any dangling references will cause no harm.
      demo_exception.cpp is a program that illustrates this case.

  4. Other cases

    Situations not covered above are pointers for which the classifications of referenced and owned are not applicable. This might occur where pointers are created by one class but consumed and deleted by another. These may be addressed with an ad hoc analysis similar to the above. As the situation becomes more complex this becomes more difficult and error prone. Eventually, it will be have to addressed by building heap management into the pointer itself - that is into boost::shared_ptr. The library includes serialization of boost::shared_ptr. As previously mentioned, this required a tiny alteration in one of the boost::shared_ptr implementation files in order to permit access by the serialization system.

Revised 24 January, 2004

© Copyright Robert Ramey 2002-2004. All Rights Reserved.