You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@zookeeper.apache.org by Deepak Jagtap <de...@maxta.com> on 2012/10/12 21:59:56 UTC
Memory leaks in zoo_multi API
Hi,
I am using zookeeper-3.4.4 and frequently using multiupdate operations.
While running valgrind it returned following output:
==4056== 2,240 (160 direct, 2,080 indirect) bytes in 1 blocks are
definitely lost in loss record 18 of 24
==4056== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
==4056== by 0x504D822: create_completion_entry (zookeeper.c:2322)
==4056== by 0x5052833: zoo_amulti (zookeeper.c:3141)
==4056== by 0x5052A8B: zoo_multi (zookeeper.c:3240)
Just curious do I need explicitly need to handle this cleanup, by
invoking some API or is this a memory leak?
It looks like completion entries for individual operations in
multiupdate transaction are not getting freed. The memory leak size
depends on the number of operations in single mutlipupdate
transaction.
Thanks & Regards,
Deepak
Re: Memory leaks in zoo_multi API
Posted by Deepak Jagtap <de...@maxta.com>.
Using synchronous version of the API (zoo_multi).
On Fri, Oct 12, 2012 at 3:34 PM, Marshall McMullen <
marshall.mcmullen@gmail.com> wrote:
> We've done massive leak detection against this code with tcmalloc's debug
> library and not seen a memory leak. And we used Multi ops almost
> exclusively.
> Perhaps valgrind is doing a better job of finding the leak than tcmalloc.
>
> Are you using the synchronous or asynchronous version of multi?
> e.g. zoo_multi or zoo_amulti ?
>
> On Fri, Oct 12, 2012 at 1:59 PM, Deepak Jagtap <deepak.jagtap@maxta.com
> >wrote:
>
> > Hi,
> >
> > I am using zookeeper-3.4.4 and frequently using multiupdate operations.
> >
> > While running valgrind it returned following output:
> >
> > ==4056== 2,240 (160 direct, 2,080 indirect) bytes in 1 blocks are
> > definitely lost in loss record 18 of 24
> > ==4056== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
> > ==4056== by 0x504D822: create_completion_entry (zookeeper.c:2322)
> > ==4056== by 0x5052833: zoo_amulti (zookeeper.c:3141)
> > ==4056== by 0x5052A8B: zoo_multi (zookeeper.c:3240)
> >
> > Just curious do I need explicitly need to handle this cleanup, by
> > invoking some API or is this a memory leak?
> >
> > It looks like completion entries for individual operations in
> > multiupdate transaction are not getting freed. The memory leak size
> > depends on the number of operations in single mutlipupdate
> > transaction.
> >
> > Thanks & Regards,
> >
> > Deepak
> >
>
Re: Memory leaks in zoo_multi API
Posted by Marshall McMullen <ma...@gmail.com>.
We've done massive leak detection against this code with tcmalloc's debug
library and not seen a memory leak. And we used Multi ops almost
exclusively.
Perhaps valgrind is doing a better job of finding the leak than tcmalloc.
Are you using the synchronous or asynchronous version of multi?
e.g. zoo_multi or zoo_amulti ?
On Fri, Oct 12, 2012 at 1:59 PM, Deepak Jagtap <de...@maxta.com>wrote:
> Hi,
>
> I am using zookeeper-3.4.4 and frequently using multiupdate operations.
>
> While running valgrind it returned following output:
>
> ==4056== 2,240 (160 direct, 2,080 indirect) bytes in 1 blocks are
> definitely lost in loss record 18 of 24
> ==4056== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
> ==4056== by 0x504D822: create_completion_entry (zookeeper.c:2322)
> ==4056== by 0x5052833: zoo_amulti (zookeeper.c:3141)
> ==4056== by 0x5052A8B: zoo_multi (zookeeper.c:3240)
>
> Just curious do I need explicitly need to handle this cleanup, by
> invoking some API or is this a memory leak?
>
> It looks like completion entries for individual operations in
> multiupdate transaction are not getting freed. The memory leak size
> depends on the number of operations in single mutlipupdate
> transaction.
>
> Thanks & Regards,
>
> Deepak
>
Re: Memory leaks in zoo_multi API
Posted by Ted Dunning <te...@gmail.com>.
Can you provide sample code and more detailed replication instructions?
On Fri, Oct 12, 2012 at 6:06 PM, Deepak Jagtap <de...@maxta.com>wrote:
> Sure, just reported this on jira!
>
> Thanks & Regards,
> Deepak
>
> On Fri, Oct 12, 2012 at 1:01 PM, Michi Mutsuzaki <michi@cs.stanford.edu
> >wrote:
>
> > Hi Deepak,
> >
> > It's most likely a memory leak. Could you open a jira for this?
> >
> > Thanks!
> > --Michi
> >
> > On Fri, Oct 12, 2012 at 12:59 PM, Deepak Jagtap <deepak.jagtap@maxta.com
> >
> > wrote:
> > > Hi,
> > >
> > > I am using zookeeper-3.4.4 and frequently using multiupdate operations.
> > >
> > > While running valgrind it returned following output:
> > >
> > > ==4056== 2,240 (160 direct, 2,080 indirect) bytes in 1 blocks are
> > > definitely lost in loss record 18 of 24
> > > ==4056== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
> > > ==4056== by 0x504D822: create_completion_entry (zookeeper.c:2322)
> > > ==4056== by 0x5052833: zoo_amulti (zookeeper.c:3141)
> > > ==4056== by 0x5052A8B: zoo_multi (zookeeper.c:3240)
> > >
> > > Just curious do I need explicitly need to handle this cleanup, by
> > > invoking some API or is this a memory leak?
> > >
> > > It looks like completion entries for individual operations in
> > > multiupdate transaction are not getting freed. The memory leak size
> > > depends on the number of operations in single mutlipupdate
> > > transaction.
> > >
> > > Thanks & Regards,
> > >
> > > Deepak
> >
>
Re: Memory leaks in zoo_multi API
Posted by Deepak Jagtap <de...@maxta.com>.
Sure, just reported this on jira!
Thanks & Regards,
Deepak
On Fri, Oct 12, 2012 at 1:01 PM, Michi Mutsuzaki <mi...@cs.stanford.edu>wrote:
> Hi Deepak,
>
> It's most likely a memory leak. Could you open a jira for this?
>
> Thanks!
> --Michi
>
> On Fri, Oct 12, 2012 at 12:59 PM, Deepak Jagtap <de...@maxta.com>
> wrote:
> > Hi,
> >
> > I am using zookeeper-3.4.4 and frequently using multiupdate operations.
> >
> > While running valgrind it returned following output:
> >
> > ==4056== 2,240 (160 direct, 2,080 indirect) bytes in 1 blocks are
> > definitely lost in loss record 18 of 24
> > ==4056== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
> > ==4056== by 0x504D822: create_completion_entry (zookeeper.c:2322)
> > ==4056== by 0x5052833: zoo_amulti (zookeeper.c:3141)
> > ==4056== by 0x5052A8B: zoo_multi (zookeeper.c:3240)
> >
> > Just curious do I need explicitly need to handle this cleanup, by
> > invoking some API or is this a memory leak?
> >
> > It looks like completion entries for individual operations in
> > multiupdate transaction are not getting freed. The memory leak size
> > depends on the number of operations in single mutlipupdate
> > transaction.
> >
> > Thanks & Regards,
> >
> > Deepak
>
Re: Memory leaks in zoo_multi API
Posted by Michi Mutsuzaki <mi...@cs.stanford.edu>.
Hi Deepak,
It's most likely a memory leak. Could you open a jira for this?
Thanks!
--Michi
On Fri, Oct 12, 2012 at 12:59 PM, Deepak Jagtap <de...@maxta.com> wrote:
> Hi,
>
> I am using zookeeper-3.4.4 and frequently using multiupdate operations.
>
> While running valgrind it returned following output:
>
> ==4056== 2,240 (160 direct, 2,080 indirect) bytes in 1 blocks are
> definitely lost in loss record 18 of 24
> ==4056== at 0x4A04A28: calloc (vg_replace_malloc.c:467)
> ==4056== by 0x504D822: create_completion_entry (zookeeper.c:2322)
> ==4056== by 0x5052833: zoo_amulti (zookeeper.c:3141)
> ==4056== by 0x5052A8B: zoo_multi (zookeeper.c:3240)
>
> Just curious do I need explicitly need to handle this cleanup, by
> invoking some API or is this a memory leak?
>
> It looks like completion entries for individual operations in
> multiupdate transaction are not getting freed. The memory leak size
> depends on the number of operations in single mutlipupdate
> transaction.
>
> Thanks & Regards,
>
> Deepak