, then forgot to delete it. Fixed.
Thanks for pointing that out; I'm not normally so sloppy.
On Mon, Dec 21, 2009 at 11:19 AM, Oleg Smolsky oleg.smol...@gmail.com
wrote:
BTW, you've added this line to stubs/hash.h
#include ext/hash_map
but it should not be there. Includes are already handled
* {
inline size_t operator()(const char* str) const {
size_t result = 0;
for (; *str != '\0'; str++) {
result = 5 * result + *str;
}
return result;
}
};
On Mon, Dec 21, 2009 at 10:44 AM, Oleg Smolsky oleg.smol...@gmail.comwrote:
Hey Kenton, you also need
On Dec 17, 12:27 pm, Kenton Varda ken...@google.com wrote:
On Thu, Dec 17, 2009 at 2:47 AM, a...@sibmail.ru wrote:
Hello,
You should use same runtime library setting to build your application and
protobuffer libraries.
Specifically, debug vs. release, single-threaded vs. multi-threaded,
Checker?
Oleg.
On 2009/5/15 15:58, Kenton Varda wrote:
Can you get stack traces for these?
I ran the whole protobuf test suite with the google-perftools leak
checker and didn't detect any leaks.
On Thu, May 14, 2009 at 4:05 PM, Oleg Smolsky o...@smolsky.net
mailto:o...@smolsky.net wrote
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,
to the heap block is never
lost, but it is never deallocated either. The fix is trivial - all that
is needed is the destructor. This, of course, assumes that the main
thread would exit only after all additional workers are dead.
Oleg.
On 2009/5/15 17:28, Oleg Smolsky wrote:
Actually, I got lucky
the shutdown function registry is once-initialized. So, sure,
use destructors. Do you want to send me a patch since you're set up
to test it?
On Fri, May 15, 2009 at 5:41 PM, Oleg Smolsky o...@smolsky.net
mailto:o...@smolsky.net wrote:
...sent the message too quickly.
So
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
