science/dlib-cpp reveals an interesting scenario that works fine on
other platforms but not on FreeBSD; notably, it ends up creating a new
global object from some destructor which is called during
__cxa_finalize. This breaks when libdlib is dlopen()ed and then
subsequently dlclose()ed, as we never end up invoking the created
object's dtor until program exit when the shlib is already unmapped.
Fix it by noting when we're in the middle of __cxa_finalize for a dso,
and then restarting the search if __cxa_atexit() was called in the
middle somewhere.
We wait until we've processed the initial set before starting over and
processing the newly added handlers as if it were a complete set of
handlers added during runtime. The alternative is calling them as
they're added to maintain a LIFO in terms of total ordering, but in
theory a constructor could add another global object that also needs to
be destroyed, and that object needs to be destroyed after the one that
constructed it to avoid creating unexpected lifetime issues.
This manifests in the pdlib PHP extension for dlib crashing, see [0].
[0] https://github.com/goodspb/pdlib/issues/39
PR: 285870
Reviewed by: kevans (also supplied commit message)
(cherry picked from commit 23427c8e1fedb9fc68ad0bd27a59c7ffd2b3008c)