Re: [boost] "peer reviewed" - Rights and responsibilities of maintainers

Subject: Re: [boost] "peer reviewed" - Rights and responsibilities of maintainers
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-10-17 07:06:10

> Again, though, this is a side track.  My main point is that if you 
> find yourself asking "has this object been destroyed?" then it's 
> usually a sign of a more fundamental lifetime mismatch, and it's 
> probably worthwhile exploring that.

This is true. But:

a) is_destroyed is part of the public interface of Boost.Serialization 
(see the docs) and it doesn't return true when it should as shown by 
#110 even in the case of a simple executable.
b) In the case I described and tested with #111 (and now even with #128) 
There are 2 shared libraries with their own instances of the singletons 
(this can be checked by debugging the ctor/dtor of them). The lifetime 
mismatch happens due to "some linux mechanism" destroying same types 
from different libraries at the same time invalidating the expectation 
of each library. Example (actually witnessed by printf-debugging)

singleton<A> (0xlib1)
singleton<B> (0xlib1)
singleton<A> (0xlib2)
singleton<B> (0xlib2)
~singleton<B> (0xlib2)
~singleton<A> (0xlib2)
~singleton<A> (0xlib1)
~singleton<B> (0xlib1)
Note the switched order of the lib1 destruction. You can verify this 
yourself with #111 or #128. The problem arises because singleton<B> 
accesses singleton<A> in both its ctor and dtor but that has been 
destroyed and due to a) above this is not detected.

We CAN try to find the reason for the mixup, OR we can rely on the 
public interface of singleton and detect it and handle it gracefully. 
The former is VERY hard, the latter is easy and actually it *is 
currently being done*!!! See 
https://github.com/boostorg/serialization/pull/105/commits/89d0910033527c34f04944d6499b788cb278761b 
All that is missing to avoid the crash is the fix for `is_destroyed`