serialization library leaks memory in its global object
Dear all, we were transferring to Boost 1.41 but came across some serious issues in Boost.Serialization. The first is already adressed in a previous post, but now the M$ crt reports a memory leak when using Boost.Serialization in combination of pointers. I think it is located in 'basic_iarchive_impl::load_pointer' where an object is allocated and added to a global object ('object_id_vector') but never released. I know that we might end up here in an argument about the defintion of a memory leak, but the fact remains that the crt just reports it on program closure and until now we never had any reports of that type. If we have to think about every report dumped by the crt, it's just unacceptable. It's like a broken window syndrome; in the end u can not distinguish between false and correct reports. Code: #include <sstream> #include <boost\smart_ptr\make_shared.hpp> #include <boost\archive\xml_oarchive.hpp> #include <boost\archive\xml_iarchive.hpp> struct Foo { template <class Archive> void serialize(Archive& /*ar*/, const unsigned int /*version*/) { } }; int main() { #ifdef _DEBUG _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_CHECK_ALWAYS_DF | _CRTDBG_LEAK_CHECK_DF); #endif std::stringstream sstr; boost::shared_ptr<Foo> ptrFoo = boost::make_shared<Foo>(); { boost::archive::xml_oarchive oa(sstr); oa << boost::serialization::make_nvp("v", ptrFoo); } boost::archive::xml_iarchive ia(sstr); ia >> boost::serialization::make_nvp("v", ptrFoo); return 0; }
gast128 wrote:
Dear all,
we were transferring to Boost 1.41 but came across some serious issues in Boost.Serialization.
The first is already adressed in a previous post, but now the M$ crt reports a memory leak when using Boost.Serialization in combination of pointers.
Note that this weekend I addressed one report of a memory leak which was detected upon application exit. It's checked into the trunk. You might want to check to see if that addresses the problem. Robert Ramey
On Mon, Nov 30, 2009 at 9:02 AM, Robert Ramey <ramey@rrsd.com> wrote:
gast128 wrote:
Dear all,
we were transferring to Boost 1.41 but came across some serious issues in Boost.Serialization.
The first is already adressed in a previous post, but now the M$ crt reports a memory leak when using Boost.Serialization in combination of pointers.
Note that this weekend I addressed one report of a memory leak which was detected upon application exit. It's checked into the trunk. You might want to check to see if that addresses the problem.
Is it possible to let the user manage the lifetime of the type registry of the serialization library? I think that would not impose much difficulties on the user, the type registry could just be associated with archive objects before they're used, that is, the library itself will get to it through the archive. Note that with this setup the user still has the option to make the type registry global if that's what they want. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Emil Dotchevski wrote:
On Mon, Nov 30, 2009 at 9:02 AM, Robert Ramey <ramey@rrsd.com> wrote:
Is it possible to let the user manage the lifetime of the type registry of the serialization library? I think that would not impose much difficulties on the user, the type registry could just be associated with archive objects before they're used, that is, the library itself will get to it through the archive.
Note that with this setup the user still has the option to make the type registry global if that's what they want.
This is effectively what happens if one uses the "registration" method which has always been available. Robert Ramey
On Mon, Nov 30, 2009 at 12:52 PM, Robert Ramey <ramey@rrsd.com> wrote:
Emil Dotchevski wrote:
On Mon, Nov 30, 2009 at 9:02 AM, Robert Ramey <ramey@rrsd.com> wrote:
Is it possible to let the user manage the lifetime of the type registry of the serialization library? I think that would not impose much difficulties on the user, the type registry could just be associated with archive objects before they're used, that is, the library itself will get to it through the archive.
Note that with this setup the user still has the option to make the type registry global if that's what they want.
This is effectively what happens if one uses the "registration" method which has always been available.
Ah right, it makes sense. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Robert Ramey <ramey <at> rrsd.com> writes:
Note that this weekend I addressed one report of a memory leak which was detected upon application exit. It's checked into the trunk. You might want to check to see if that addresses the problem.
Thx, but could u be more specific? From the Trunk I see a lot of changes. Trac item 3412 adressess a memory leak but this is already solved in 1.41
participants (3)
-
Emil Dotchevski -
gast128 -
Robert Ramey