Memory leak in serialization 1.65

[anonymous]

Hi, we are seeing a seg fault seemingly caused by a difference between boost serialization 1.64 and 1.65 (no problems in 1.64 or any other boost we are currently testing >1.48 as part of Chaste computational physiology library). Unfortunately the minimal failing test is a bit complicated I'm afraid, this only seems to show up with a hierarchy of serialization classes.

I've attached valgrind memory testing output which should hopefully give all the clues needed to track it down:

==20488== Memcheck, a memory error detector
==20488== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==20488== Using Valgrind-3.10.1 and LibVEX; rerun with -h for copyright info
==20488== Command: mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner -malloc_debug -malloc_dump -memory_info
==20488== Parent PID: 20487
==20488== 
==20488== Invalid read of size 8
==20488==    at 0x7E55025: boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x4756E6: boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> >::~extended_type_info_typeid() (extended_type_info_typeid.hpp:96)
==20488==    by 0x474F02: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/garmir/workspace/Chaste/mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==  Address 0x17bd1740 is 32 bytes inside a block of size 40 free'd
==20488==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20488==    by 0x7E55572: boost::serialization::singleton<std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x9E2E539: __cxa_finalize (cxa_finalize.c:56)
==20488==    by 0x7E4D402: ??? (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x40108D9: _dl_fini (dl-fini.c:252)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488== 
==20488== Invalid read of size 8
==20488==    at 0x7E55036: boost::serialization::typeid_system::extended_type_info_typeid_0::type_unregister() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x4756E6: boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> >::~extended_type_info_typeid() (extended_type_info_typeid.hpp:96)
==20488==    by 0x474F02: boost::serialization::singleton<boost::serialization::extended_type_info_typeid<AbstractTetrahedralMesh<3u, 3u> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/garmir/workspace/Chaste/mesh/build/debug_hostconfig,boost=1-65/TestNodesOnlyMeshRunner)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)
==20488==  Address 0x17bd1738 is 24 bytes inside a block of size 40 free'd
==20488==    at 0x4C2C2BC: operator delete(void*) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==20488==    by 0x7E55572: boost::serialization::singleton<std::multiset<boost::serialization::typeid_system::extended_type_info_typeid_0 const*, boost::serialization::typeid_system::type_compare, std::allocator<boost::serialization::typeid_system::extended_type_info_typeid_0 const*> > >::get_instance()::singleton_wrapper::~singleton_wrapper() (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x9E2E539: __cxa_finalize (cxa_finalize.c:56)
==20488==    by 0x7E4D402: ??? (in /home/robert/boost_1_65/lib/libboost_serialization.so.1.65.0)
==20488==    by 0x40108D9: _dl_fini (dl-fini.c:252)
==20488==    by 0x9E2E1A8: __run_exit_handlers (exit.c:82)
==20488==    by 0x9E2E1F4: exit (exit.c:104)
==20488==    by 0x9E13F4B: (below main) (libc-start.c:321)

Incidentally, the consequences are exactly the same as a problem that existed in boost 1.46 and was fixed in 1.48. I don't know if the underlying problem is related.

[gary.mirams@…]

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

[gary.mirams@…]

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

[Gary Mirams <gary.mirams@…>]

Perhaps related to these changes: ​https://github.com/boostorg/serialization/commit/b0a794da38b52c8ae0f8155cf3bb30321cf67f00 ?

[anonymous]

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]

Backing out changes to singleton.hpp solves the issue.

Need to know the implication of it ?

[James E. King, III]

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

[gast128@…]

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@…]

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]

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

[David]

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]

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]

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!