Boost logo

Boost Users :

Subject: Re: [Boost-users] crash in boost serialization (1.44)
From: Robert Ramey (ramey_at_[hidden])
Date: 2010-12-15 17:22:52


Guy Prémont wrote:
>>>> From what I understand, the singleton creation for serialization of
>> a
>>>> type
>>> (Node here) is a side effect of calling on serialization for that
>>> type.
>>
>> more or less. actually it's a side-effect of exporting a type.
>>
>>>
>>> I haven't found the trap that you mentioned a few times. Could you
>>> give me a pointer to it? I'd like to enable it and see what it says
>> in
>>> my application.
>>
>> It's in (I think) basic_serializer_map.?pp). It's commented out.
>>
>>
>> Robert Ramey
>>
>>
>
> Thanks for the tip. I re-activated the trap... and indeed i found some
> serialization code that was in several DLLs. However, even though I
> fixed the problems I found, the trap did spring up again at code that
> I know is not duplicated across DLLs.
> I still think that the singleton creation is not only a side-effect of
> exporting a type (using BOOST_CLASS_EXPORT_IMPLEMENT) but also
> happens when using the serialization for a given type ( à la "ar &
> t"). It is a quite complex behavior, I don't understand it completely
> because from my understanding I expected a lot more trapping to
> happen.

As I suppose it's obvious by now, this is uncharted territory. So
I appreciate your efforts to clarify this. Eventually I want to include
code to improve handling of this issue and hopefully you'll be able
to provide some insight. Here are some other things to look at.

a) You can set your debugger to trap each time an entry is added to
a serializer_map singleton. A backtrace should (?) lead you to the
source which get's added twice.

b) If you haven't already, you might want to look at the tests of
DLLS in the test suite. I don't know if that will help as they are
pretty simple but it wouldn't hurt to look.

Robert Ramey


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net