A little extra information would be helpful. a) what compiler/linker etc are you using b) which version of boost serialization are you using. c) what kind of library: static, DLL, or? d) Is this an issue related to shared_ptrs or more general? Robert Ramey Hughes, James wrote:
Hello all,
I am a bit stumped by a problem I am seeing with serialisation, and wondered whether it may be due to the way I sue some libraries.
I have two libraries, one which contains the main code that uses serialisation, and another which contains some small classes used by the main code.
The main code serialises a tree like data structure containing some shared pointers, each node of the 'tree' contains member data, and its one of these members that is causing a double free or corruption error on loading. This particular member is a structure from the other library. It contains a serialisation template in the class header which appears to save correctly - the XML output all appears correct. However on loading the double free error occurs.
I cannot see anything wrong with the code at all. The only thing I can think of is that there are limitations in doing serialisation across the library boundary. Perhaps I end up with two instantiations of the template for serialisation? One in the main library, and one in the small library? Am I clutching at straws? DO I somehow have to force the instantiation of the serialisation for the class in the sub library to be in there, rather than being created again in the main library?
Any thoughts?
James
This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.