Re: [boost] [Boost.Serialization] Crash in current master (1.68)

Subject: Re: [boost] [Boost.Serialization] Crash in current master (1.68)
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-07-02 15:46:00

> test results to see if I could find a commonality between the test 
> failures and the configuration being tested.  I found that:
>
> a) Test failed only on linux platforms.  But the test doesn't fail on 
> all linux platforms.
> b) Test never fails on windows platforms.
> c) tests would fail with both clang and gcc compilers
> d) Test failure seems pretty reliable.  Exception: the one test which 
> passes uses gcc 7.3
> e) I can't discern what the build switch settings are from the python 
> command line.  That is I would like to know if it was built with 
> link=shared/static and runtime-link=shared/static.  I believe that 
> this information would be significant.
> f) a couple of ARM tests pass - one fails.
Great! I found at least for 
https://www.boost.org/development/tests/develop/developer/output/BI1-Debian-Stretch-boost-bin-v2-libs-serialization-test-test_dll_exported-test-gcc-4-9-4-debug.html 
that boost was build with link=shared. I don't think runtime-link is 
tested? At least I'd expect a reference to that in the link command. But 
I don't think it matters much, if the test I sent is considered formally 
valid (see below)
> Much has been made of a memory leak.  The current version 1.68 on 
> develop and master branches removed the dynamic allocation in the 
> singleton module.  So if there is a memory leak it would be more 
> subtle than first meets the eye.  I believe this memory leak was 
> introduced in efforts to make this test pass for 1.67 (or maybe 1.66 I 
> don't remember).
FYI: The leak was introduced in 1.66, the crash in 1.65.0 and again in 
current master.
> I believe the correct way to approach this is to analyze your new test 
> and also test_dll_export in light of Gavin Lambert's comments above.  
> If this works out, I would then add this information to the 
> serialization library documentation.
To make it simple I'd suggest you concentrate on my new test. I'm sure 
it meets Gavin Lambert's requirements of not leaking Boost-"internals" 
outside of the shared libs used and the crash is easy to reproduce (at 
least on my side`on every linux machine). If you can reproduce this even 
on a single machine on your side, then this is all argument it needs 
that there is something in need of fixing.

But even without this: Isn't it enough, that `is_destroyed` is broken, 
to investigate in my fix? Fixing that function is the major part of the 
PR. The rest is the simple check-before-use stuff.

Alex