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