Boost C++ Libraries: Ticket #13186: Memory leak in serialization 1.65

attachment set

gary.mirams@… — Fri, 01 Sep 2017 10:26:32 GMT

attachment → memory_output.txt

full valgrind output (ignore PETSc stuff - that always happens!)

gary.mirams@… — Fri, 01 Sep 2017 10:28:33 GMT

This was submitted by Gary Mirams <gary.mirams@…> I failed to log in to trac properly, sorry

Fri, 01 Sep 2017 11:04:40 GMT

anonymous — Wed, 27 Sep 2017 05:24:20 GMT

We are also getting the segmentation fault (double free or corruption (fasttop): 0x00000000007e0730 )

#5 0x00007ffff59d1d14 in boost::serialization::extended_type_info::key_unregister() const ()

from glnxa64/libmwboost_serialization.so.1.65.0

#6 0x000000000050ebde in boost::serialization::extended_type_info_typeid<Message>::~extended_type_info_typeid (this=0x7cbd80, in_chrg=<optimized out>)

at boost/serialization/extended_type_info_typeid.hpp:128

#7 0x000000000050da6a in boost::serialization::singleton<boost::serialization::extended_type_info_typeid<Message> >::get_instance()::singleton_wrapper::~singleton_wrapper() (this=0x7cbd80,

in_chrg=<optimized out>) at /boost/include/boost/serialization/singleton.hpp:150

#8 0x00007ffff4841b29 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #9 0x00007ffff4841b75 in exit () from /lib/x86_64-linux-gnu/libc.so.6 #10 0x00007ffff482bb4c in libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #11 0x00000000004accf9 in _start ()

Also getting same memory leak logs as mentioned in bug.

This is stopping our upgrade to latest 1.65

anonymous — Wed, 27 Sep 2017 12:29:45 GMT

Backing out changes to singleton.hpp solves the issue.

Need to know the implication of it ?

James E. King, III — Fri, 20 Oct 2017 20:52:36 GMT

See https://github.com/boostorg/serialization/pull/69 for more details. Someone submitted a fix.

gast128@… — Mon, 29 Jan 2018 15:21:37 GMT

This is breaking for us and still present in 1.66. We look at the Visual Studio output and it should be clean. Once memory leak reports appear there one won't be able to distinguish a benign one from a serious one.

The destructor of the singleton (which would free the memory) is never called. Trying to work around and making a singleton by hand leads to a stack overflow (0xC00000FD):

struct Bla
{
    template <class Archive>
    void serialize(Archive& ar, const unsigned int version)
    {
        ar & boost::serialization::make_nvp("m_n", m_n);
    }
    int m_n;
};
const boost::serialization::singleton<boost::serialization::extended_type_info_typeid<Bla>> g_singleton;

gast128@… — Tue, 30 Jan 2018 11:51:39 GMT

Copy of my GitHub comment:

The Boost.Serialization singleton is never cleaned up leading to memory leaks. Even more severely it seems to crash our application now if a DLL's is dynamically unloaded and loaded. It seems related to registration of types in a singleton.

anonymous — Tue, 20 Mar 2018 09:34:22 GMT

So, what is the current state of this? To put it mildly, this is quite annoying.

David — Wed, 28 Mar 2018 07:44:02 GMT

Hi guys, just tripped over this as well.

I'm using VS2017, and using the serialization library now produces memory leaks when the program is terminated.

I see that in the Boost beta 1.67 release notes there's nothing there related to this problem. Is someone looking at the issue?

Tobias Loew — Wed, 11 Apr 2018 16:53:49 GMT

Hi,

I've also noted the memory-leaks. They origin from https://github.com/boostorg/serialization/pull/79 I (tobias-loew) already tried to convince those guys that they're off tracks but they seem resistant to advice. Please help here https://github.com/boostorg/serialization/issues/102 to convince Robert Ramey to revert those changes.

anonymous — Fri, 22 Jun 2018 01:17:59 GMT

Same issue. Our team is moving to VS2017, and Boost 1.67 was supposed to be the first release with official support for that compiler/build environment, so we switched over to it. And now we're getting spammed with memory leak notifications in debugger console, upon program exit. Very disappointing to see this is still a problem 10 months after the bug was first reported!