I cannot get stack traces with VS. I can add a macro to every
compilation unit that wraps new so that __FILE__ and __LINE__ are
recorded. It's quite a bit of work to re-arrange your header files,
though. Would that suffice? Alternatively, do you happen to have a 3rd
party tracker like Bounds
Actually, I got lucky - the culprit was not in headers. It's this line
in once.cc:
if (internal_ == NULL) internal_ = new GoogleOnceInternal;
The log is as follows:
Detected memory leaks!
Dumping objects -
..\src\google\protobuf\stubs\once.cc(65) : {1438} client block at
0x00B92620,
...sent the message too quickly.
So, the fix is trivial, yet it comes down to the same very discussion as
the original issue. In this case it's cleaning up after the cleaners :)
It's a global pointer that is initialized when global constructors
(a.k.a. static initializers) run. The pointer to
Here we go.
On 2009/5/15 18:56, Kenton Varda wrote:
Ugh, I missed that one because I was doing my testing on Linux and
that is in Windows-only code.
Ideally I'd prefer if each GoogleOnce object registered a shutdown
function for itself. But I suppose that could create a deadlock
because
FYI: This is fixed in the 2.1.0 release (you can call
google::protobuf::ShutdownProtobufLibrary() to clean up all leaks).
On Fri, Mar 27, 2009 at 7:07 PM, Kenton Varda ken...@google.com wrote:
On Fri, Mar 27, 2009 at 4:30 PM, Oleg Smolsky o...@smolsky.net wrote:
So, the next question is -
On 3/27/2009 3:19 PM, Oleg Smolsky wrote:
Weird... DescriptorPool is destroyed, and so it DescriptorPool::Tables
which frees its 52 outstanding allocations...
OK, I made a silly mistake - I was dumping allocations before static
destructors were executed. Oops.
I've just verified the test and
