Boost logo

Boost :

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
All that is missing to avoid the crash is the fix for `is_destroyed`

Boost list run by bdawes at, gregod at, cpdaniel at, john at