troy d. straszheim wrote:
Ruediger Berlich wrote:
Hi Troy,
gdb reports:
Program received signal SIGSEGV, Segmentation fault. 0x00007ffff60274b8 in boost::serialization::void_cast_detail::void_caster::recursive_unregister() const () from /opt/boost139/lib/libboost_serialization-gcc43-mt-1_39.so.1.39.0
FYI - one of the most significant changes from 1.38 to 1.39 is a change to void_cast system. Pre 1.38 void_cast was not thread safe. 1.38 made void_cast (and the whole library) threadsaft. But the required void_cast implementation was very, very slow. The changes in 1.39 correct the speed problem while still keeping the library thread safe at the cost of making void_cast ever more subtle and intricate. It would be fairly easy to test this by running the serializaiton tests and verifying that only those tests which invoke void cast are the ones that fail.
More (albeit IMHO not very helpful) details from the backtrace can be found at the end of this post. Somehow looks like an infinite recursion ? Note that I can of course not rule out a problem in my own code. However, this "feels" like the pre-1.38 problem in that it does not affect the runtime behaviour of my programs (nor of the library's tests) and that the segfault happens after the last statement in main(). And as I said, the code runs fine with 1.38 .
Hm. I can't reproduce it. I'm not getting the error with the release beta.
One thing I stumbled on when looking at this last time was the following gcc flag:
----
-fuse-cxa-atexit
Register destructors for objects with static storage duration with the __cxa_atexit function rather than the atexit function. This option is required for fully standards-compliant handling of static destructors, but will only work if your C library supports __cxa_atexit.
You could be on to something here. One thing that I discovered is that on some platforms, the order of static destructors is not necessarily the reverse order of the corresponding static constructors. To address this, we've added some extra if statements which in theory should never be necessary but seems in fact that they might be. If you could indicate the line of source code, we might be able to apply this fix. Robert Ramey
----
and as I recall, '-fno-use-cxa-atexit' was on by default on the linux distribution I was on (might have been ubuntu 8.04). I'm still curious as to when that flag could possibly be useful.
-t
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost