memory leak in singleton

[tobias-loew]

After commit 7d216b4 (where singleton_wrapper is now allocated on the heap (include/boost/serialization/singleton.hpp:138)) Visual Studio reports memory leaks for those allocated objects.

[tobias-loew]

It seems that the destructor of singleton never gets called. IMHO returning the pointer as a reference and binding it to singleton:::m_instance won't call the destructor at exit, since there is no temporary object whose lifetime got expanded.

[res2k]

~singleton() should delete the instance, so the question is why it isn't called.

[tobias-loew]

There are no singleton-instances in my code. IMHO singletons are TYPES with static methods (e.g. get_const_instance() or get_mutable_instance()).
Before the change everything worked fine.
And by the way, the singleton destructor won't even compile for types with protected dtors since it doesn't use a singleton_wrapper<T&> static-cast for the delete-call.
Since nobody complained about that, I assume the singleton-dtor doesn't get called at all. (Also here #79 in vasild's comment on Nov 22, 2017 there are 1,544 bytes leaking - and nobody seems to care!)

[gast128]

This is severe. We track memory leaks by looking at Visual Studio output windows after program close and this Boost.Serialization library is currently spamming the whole output window. Even if they are only initialization issues, they mask other memory leak reports.

Even more severely it seems to crash our application now if a DLL's is dynamically unloaded and loaded.

[Flamefire]

@res2k ~singleton is not called because singleton is never instantiated. See #104

[robertramey]

fixed

[Flamefire]

Please note that your fix reverts to 1.65.x behaviour causing crashes (see test_dll_exported) and also is_destroyed is still dysfunctional (see my test cases). So please do not include it in future Boost releases until #104 is dealt with