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`