Memory leaks in VS2008 using 2.4.1

[Eric Holtman]

I've tried building the library as static. I've tried building the
library as dll. I've even gone so far as starting from scratch and
building my own project, and including all the .cc and .h files.

I cannot make the memory leaks on program exit go away.

I am definitely calling google::protobuf::ShutdownProtobufLibrary ();

I have traced through, and it *looks* like it's getting to the
"OnShutdown" functions for my .proto generated message files, and
calling delete. I am definitely calling Shutdown *before* the leak
checker runs.

And yet, I still get reported memory leaks.

I don't really want to ignore the leaks, because sooner or later,
that's going to hide a real error.

Am I not doing something correctly? Is there any way to fix this.

[Henner Zeller]

Can you drill down _what_ object is leaking ? In particular, did you
narrow down that it is indeed protobufs that cause the leak ?
You need to find the leaking object first, otherwise it is a bit hard
do diagnose what is going on.

-h

>
> --
> You received this message because you are subscribed to the Google Groups "Protocol Buffers" group.
> To post to this group, send email to prot...@googlegroups.com.
> To unsubscribe from this group, send email to protobuf+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/protobuf?hl=en.
>

[Eric J. Holtman]

On 3/26/2012 7:25 PM, Henner Zeller wrote:
>
> Can you drill down _what_ object is leaking ? In particular, did you
> narrow down that it is indeed protobufs that cause the leak ?
> You need to find the leaking object first, otherwise it is a bit hard
> do diagnose what is going on.
>

I just finally got around to figuring it out this afternoon,
after spending the morning fighting with my debugging tools.

It's line 85 in parser.cc:

const TypeNameMap kTypeNames = MakeTypeNameTable();

I have done some more poking around, and I can't tell if what
is happening is that the destructor for that hash_map isn't
getting called (unlikely), or that it's getting called after
the MSFT memory tracer has already run (which I would find
more likely).

I've tried a couple of different ways to use libprotobuf (static,
dll, etc), and they all seem to exhibit this behavior.

I'm really leaning towards "it's an order of initialization
problem" at this point, and I might have to just eat the
warnings, unless someone sees the kTypeNames variable there
and says "oh yeah, I know what's going on there".

[Eric Holtman]

On Mar 26, 7:41 pm, "Eric J. Holtman" <e...@holtmans.com> wrote:
>
> It's line 85 in parser.cc:
>
> const TypeNameMap kTypeNames = MakeTypeNameTable();
>

...

> I'm really leaning towards "it's an order of initialization
> problem" at this point, and I might have to just eat the
> warnings, unless someone sees the kTypeNames variable there
> and says "oh yeah, I know what's going on there".

It's an order-of-initialization problem. The call to is
happening in an "atexit" registered destructor for a static
object in mfc90d.dll. But the dll into which I built
libprotobuf is getting loaded before mfc90d.dll, so since
atexit() is LIFO, the dump checker is called before the
destructor for that object.

So, I don't think there's anything wrong with the protocol
buffers.

Thanks for looking,

Eric.