BTW, the only way libprotobuf allocates memory is via operator new, though
it sometimes calls it directly like:
  void* buffer = operator new(size);

So overriding operator new to collect stack traces should work.

On Fri, Mar 27, 2009 at 2:34 PM, Kenton Varda <ken...@google.com> wrote:

> On Fri, Mar 27, 2009 at 2:21 PM, Oleg Smolsky <o...@smolsky.net> wrote:
>
>>  I had seen that thread. IMO they are leaks, as the memory is still
>> allocated after main() has returned and the CRT destroyed statically
>> allocated objects. Isn't that the definition of a leak?
>>
>
> I guess in Google we define a "leak" as memory that is allocated but no
> longer reachable.  Pointers in static space are always considered reachable.
>
>
>> According to the thread, there is a body of code at Google that lets the
>> main thread exit without stopping workers. If so, I want to try adding an
>> generation option (or function?) to do this cleanup, as I stop workers in my
>> apps.
>>
>
> I was thinking that instead of an option, maybe we should just make this a
> difference between the google-internal code and open source code.
>  Personally I believe that people should be required to clean up but I've
> been shouted down by other Google engineers.
>
>
>> My question is - where do you keep all these little buffers? I've tried
>> instrumenting the code with MS debug "new",  but couldn't get it to work
>> with protobuf due to several different ways "new" is invoked.
>>
>
> I dunno.  Did you make sure that DescriptorPool::generated_pool() is
> deleted?
>
>
>>
>>
>> Thanks,
>> Oleg.
>>
>>
>> On 3/27/2009 1:12 PM, Kenton Varda wrote:
>>
>> These aren't really "leaks".  See this thread:
>>
>> http://groups.google.com/group/protobuf/browse_thread/thread/f7b2bc887780819f/c6abb9e29621160f
>>
>> On Fri, Mar 27, 2009 at 12:20 PM, Oleg Smolsky <o...@smolsky.net> wrote:
>>
>>> Hi Kenton, I was debugging a unit test that pushes protobuf messages
>>> over a TCP connection and noticed that VS2008 reports a large amount of
>>> leaks.
>>>
>>> So, I've merged/fixed the patch proposed in
>>> http://code.google.com/p/protobuf/issues/detail?id=54 (attached) and
>>> made sure that the compilation unit's static destructor runs. My current
>>> (minimal) test case does not even instantiate any messages or make any
>>> connections - only protobuf's static constructors and destructors run.
>>> The output from VS debugger is attached.
>>>
>>> It appears that a lot more stuff is allocated elsewhere. Could you point
>>> me to the right direction please?
>>>
>>> Cheers,
>>> Oleg.
>>>
>>
>>
>> >>
>>
>

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

Reply via email to