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

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
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
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
Emil Dotchevski wrote:
On Mon, Nov 30, 2009 at 9:02 AM, Robert Ramey
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
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