[Boost-users] [serialization] 1.40.00 BOOST_CLASS_EXPORT_GUID creates memory leak

Subject: [Boost-users] [serialization] 1.40.00 BOOST_CLASS_EXPORT_GUID creates memory leak
From: Todd Day (dsmtoday_at_[hidden])
Date: 2009-09-17 07:08:54

MSVC 8.0

BOOST_CLASS_EXPORT_GUID is used to create some static objects for using in
serialization.  These memory errors are not too big a deal since they aren't
runaway - ie, these objects are created at startup before main() is even
called, and the objects are not created over and over again.  They are just
not deleted at program exit, which causes my debugger to complain about
memory leaks.

I tracked the source of these leaks to two spots in the code.
Unfortunately, the code is so complicated at these points that I can't
suggest a fix or workaround.  Hopefully, the maintainers know what this is
about.

The first leak is created in
\boost_1_40_0\boost\smart_ptr\detail\shared_count.hpp line @ line 124

     pi_ = new sp_counted_impl_pd<P, D>(p, d);

I could be wrong, but it appears to me that the above problem only occurs
for serialized objects that are derived from other objects at least twice.
For example, if B is derived from A, and C is derived from B, then

     BOOST_CLASS_EXPORT_GUID(B, "B")
     BOOST_CLASS_EXPORT_GUID(C, "C")

results in a memory leak for C, but not for B.  I think, at least it looks
that way.

The second leak is created in
\boost_1_40_0\libs\serialization\src\void_cast.cpp @ line 205

        if(* (*it)->m_derived == * m_base)
            new void_caster_shortcut(
                m_derived,
                (*it)->m_base,
                m_difference + (*it)->m_difference,
                includes_virtual_base
            );

Again, it appears the these leaks only happen for classes which are derived
at least twice.

The above allocations are not deleted at shutdown.  In the second case, it
almost appears to me as if a registration function is accidentally getting
called twice, and a pointer is getting set first to one allocation and then
to a second allocation, which means the first allocation is lost track of.

Thanks for any help,
-todd-

PS - Just pulled down the latest trunk from SVN.  It appears that many
changes in the areas I've mentioned above have occurred, so maybe this issue
is fixed.  If so, I'm hoping I can just pull over the include and source
file changes made to the serialization library by themselves, but I don't
know if those changes rely on other changes in other Boost libraries.