Well, first of all, 40mb heap is not a leak, but 1gb heap probably is.

Also, can you please run valgrind --leak-check=full ... ?

Cheers,
Fedor.



On Fri, Oct 19, 2012 at 3:53 AM, Nabeel S. <[email protected]> wrote:

> Hi all,
>
> I've been working on a C++ extension for node, that takes an object, and
> then transforms it into a protocol buffer message, and then returns a
> Buffer object. It works great, and it's fast. There are some strange
> patterns in the heap total/heap used that I'm trying to understand, and
> figure out if I should be worried about them.
>
> Here are two runs, one is 30 seconds, and the other is two minutes, of the
> module running the encode and decode (as separate runs).
>
> http://i.imgur.com/i7orl.png <- 30 seconds
> http://i.imgur.com/KVGV5.png <- two minutes
> http://i.imgur.com/cYwyW.png <- another 30 second run, this shows a
> different pattern that would make more sense
>
> So, am I looking at a memory leak here? According to node-memwatch (
> https://github.com/lloyd/node-memwatch), there is no leak, when running
> it against the same tests.
>
> So, I'm curious as to what that pattern means. The code has an encode and
> decode function. They retrieve the protocol-buffers class based on
> parameters passed in, and then instantiate a class that will process the
> message, along with the parameters. It uses Handles and Locals within the
> class, and then the class returns a Handle<Object> with a FastBuffer (for
> an encode), and a nested Handle<Object> with all of the properties on
> decode. I don't use the node::Buffer class (valgrind was showing a leak
> there; I couldn't free the instance since the value was being pointed to by
> a Handle). It's nothing too fancy, just uses Reflection and Descriptors to
> recursively pass an Object that's passed by reference (bool
> NodePBMsg::readProtoObject(protobuf::Message *msg, Handle<Object>
> &return_data))
>
> Valgrind does show leaks this, no matter how many iterations or for
> however long it runs:
>
> ==4202== HEAP SUMMARY:
> ==4202==     in use at exit: 98,379 bytes in 1,589 blocks
> ==4202==   total heap usage: 173,296 allocs, 171,707 frees, 15,079,515
> bytes allocated
> ==4202==
> ==4202== LEAK SUMMARY:
> ==4202==    definitely lost: 4,509 bytes in 40 blocks
> ==4202==    indirectly lost: 8,192 bytes in 1 blocks
> ==4202==      possibly lost: 20,922 bytes in 426 blocks
> ==4202==    still reachable: 64,756 bytes in 1,122 blocks
> ==4202==         suppressed: 0 bytes in 0 blocks
> ==4202== Rerun with --leak-check=full to see details of leaked memory
> ==4202==
> ==4202== For counts of detected and suppressed errors, rerun with: -v
> ==4202== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
>
>
> Thanks for any and all guidance!
> Nabeel
>
>  --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to [email protected]
> To unsubscribe from this group, send email to
> [email protected]
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>

-- 
Job Board: http://jobs.nodejs.org/
Posting guidelines: 
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en

Reply via email to