Subject: Re: [boost] Boost.Build check to see if cxxflags flag is supported?
From: Alexander Grund (alexander.grund_at_[hidden])
Date: 2018-11-09 08:08:42
Am 09.11.18 um 06:50 schrieb degski via Boost:
> I would like to
> request for someone involved in that discussion to write a tl;dr of that
> discussion, as it seems to touch upon a number of issues that are poorly
> understood [also by long-time cpp-war-heroes] in general. /r/cpp might also
> be a good place for this and [comments] could shed more light on this.
As the original author of the PR(s) I'll do this. Note that everything
below is already explained in detail in the description of the PRs and
initial issue:
- https://github.com/boostorg/serialization/pull/111,
https://github.com/boostorg/serialization/pull/128,
https://github.com/boostorg/serialization/pull/129,
https://github.com/boostorg/serialization/pull/131
https://github.com/boostorg/serialization/issues/105
There is also my question on SO:
https://stackoverflow.com/questions/50064617/order-of-destruction-for-static-function-members-in-shared-libraries
To summarize:
There are 2 issues:
1. Wrong destruction order in shared libraries
2. Bug in Boost.Serialization (`singleton::is_destroyed`)
on 1.: As per the C++ standard the destructors are called in reverse
order of how the constructors finished. This is even true for static
initialization (pre-main) and destruction (post-main) of global static
instances which we have here.
This means if type `Foo` accesses a type `Registry` in its constructor
it is guaranteed that `Registry` will be constructed before `Foo` and
destroyed after.
Boost.Serialization makes use of this fact and lets `Foo` register
itself in `Registry` in the ctor of `Foo` and unregister in the
destructor of `Foo`.
Now there is the case of shared libraries (see also
https://github.com/boostorg/serialization/pull/131#discussion_r231498983):
Assume 2 shared libraries build against static Boost, so each of them
has separate instances of `Registry`, which is also ok.
Now lib1 uses a type `Foo` which gets registered in lib1-`Registry` and
lib2 uses a type `Bar` which gets registered in lib2-`Registry`. During
unload/destruction `Foo` is destroyed first as before and
lib1-`Registry` afterwards. But because shared library behaviour is
implementation defined we now run into the following situation on Linux
(not on OSX or Windows): With the destruction of lib1-`Registry` the
runtime also destroys lib2-`Registry`, probably because they are of the
same type. One can only guess what happens behind the scenes, but maybe
a name-map is used or so.
The problem: Now lib2-`Registry` is destroyed before `Bar` and when that
accesses the `Registry` you get a use-after-free situation and a corruption.
This can be handled (and was pre Boost 1.65) by a flag `is_destroyed`
which gets set once the singleton destructor is called and checked in
the destructors accessing another singleton. (Basically:
`if(!Registry::is_destroyed()) Registry::unregister(this)`)
but here issue 2 (introduced in 1.65):
The singleton template can be used directly by **not** inheriting from
it. In this case an instance of `T` is returned directly:
https://github.com/boostorg/serialization/blob/boost-1.68.0/include/boost/serialization/singleton.hpp#L122
BUT: The `is_destroyed` flag is set in the destructor of the singleton
template:
https://github.com/boostorg/serialization/blob/boost-1.68.0/include/boost/serialization/singleton.hpp#L157
As `T` is not inherited from `singleton<T>` this destructor
`~singleton<T>` is never called (because it is never constructed either)
and hence the flag is never set. See
https://github.com/boostorg/serialization/pull/131#discussion_r232088304
This is different when `T` is inherited from `singleton<T>` in which
case the construction of `T` will lead to the construction of
`singleton<T>` and also destruction which is why **in this case**
`is_destroyed` works correctly.
Due to this the issue 1. does not get caught and leads to the crash.
The question on this thread was now on how to include the "crash test"
into BJam:
- We need to build 2 shared libraries
- Link them into static boost
As Boost is build statically BJam does not add `-fPIC` to its compile
flags but as it is linked into shared libraries later this fails as
addresses are fixed already. Although BJam has the information (link
boost library into a shared library) it does not "backpropagate" this
into the build of boost. See
https://github.com/boostorg/serialization/pull/131#discussion_r231964634,
https://github.com/boostorg/serialization/pull/131#issuecomment-437236135
Thanks to Peter Dimovs help we got Robert convinced to include my fix
into the develop branch of Boost.Serialization:
https://github.com/boostorg/serialization/commit/f297d80d6ef55ac66525320d0477c17806aa57cd.
I now hope the tests get included to so it doesn't break in the future.