[serialization] Crashes after termination of main()
Hi there, I am consistenty getting crashes in line 80 of the file /opt/boost136/include/boost-1_36/boost/serialization/extended_type_info_typeid.hpp , when my program exits. This is the destructor of class extended_type_info_typeid : ~extended_type_info_typeid(){ type_unregister(); } Any idea of what this is ? I'm using several singletons in my program, which according to their nature, only terminate once main() has finished. They refer to several objects which can, in other contexts, also be serialized. This specific program, however, does not make use of this option. I am pretty sure that the singletons do not refer to each other (any more) as, while searching for the problem, I have redesigned larger portions so that they don't. I'm using Boost 1.36 on OpenSUSE 11 / 64 bit (g++ 4.3.1). Thanks in any case and best regards, Ruediger
This has been previously reported and fixed in the trunk. I hope to merge this into the release branch before the end of the month. Robert Ramey Ruediger Berlich wrote:
Hi there,
I am consistenty getting crashes in line 80 of the file /opt/boost136/include/boost-1_36/boost/serialization/extended_type_info_typeid.hpp , when my program exits.
This is the destructor of class extended_type_info_typeid :
~extended_type_info_typeid(){ type_unregister(); }
Any idea of what this is ?
I'm using several singletons in my program, which according to their nature, only terminate once main() has finished. They refer to several objects which can, in other contexts, also be serialized. This specific program, however, does not make use of this option.
I am pretty sure that the singletons do not refer to each other (any more) as, while searching for the problem, I have redesigned larger portions so that they don't.
I'm using Boost 1.36 on OpenSUSE 11 / 64 bit (g++ 4.3.1).
Thanks in any case and best regards, Ruediger
Ruediger Berlich wrote:
Robert Ramey wrote:
This has been previously reported and fixed in the trunk. I hope to merge this into the release branch before the end of the month.
Robert Ramey
Robert: thanks!
Second on the thanks. This is the same thing that you said you had trouble reproducing? I'm willing to spend a significant amount of time doing a merge locally and testing, if you want to point me to the relevant commits. -t
If you can't wait, you could use the version in the trunk. There are a few changes but nothing huge. Note that on my machine here, I test against the 1.36 release and am currently passing all tests with both gcc and vc 7.1. The testers on the trunk are also passing. The only reason I don't merge into the release now is that I want to address a pending trak item and merging into the release ready branch. Also I would like to make some tweaks to make borland compilers pass failing tests. takes me a little bit of time horsing around with SVN and I'm super busy right now. Thanks for helping out. Robert Ramey troy d. straszheim wrote:
Ruediger Berlich wrote:
Robert Ramey wrote:
This has been previously reported and fixed in the trunk. I hope to merge this into the release branch before the end of the month.
Robert Ramey
Robert: thanks!
Second on the thanks. This is the same thing that you said you had trouble reproducing? I'm willing to spend a significant amount of time doing a merge locally and testing, if you want to point me to the relevant commits. -t
participants (3)
-
Robert Ramey -
Ruediger Berlich -
troy d. straszheim