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
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
> 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.