Mailing-List: contact user-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@zookeeper.apache.org
Received-SPF: pass (nike.apache.org: domain of ted.dunning@gmail.com
 designates 209.85.212.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAN0kX3Ab_inYc50bkiZB=0mPqe3iEjJy-3Tzkdcr=LiP+TbndQ@mail.gmail.com>
References: 
 <CAN0kX3AWxU1V_=MGPp1h49gc6a7wBKVOEexXbnGmaOHZpgomGA@mail.gmail.com>
 <CAHYqJpEhMcPcMi53-mUWuXCsUdXmkZsUwYi7xTA=GE7ufLTsnQ@mail.gmail.com>
 <CAN0kX3Ab_inYc50bkiZB=0mPqe3iEjJy-3Tzkdcr=LiP+TbndQ@mail.gmail.com>
From: Ted Dunning <ted.dunning@gmail.com>
Date: Fri, 12 Oct 2012 18:38:19 -0700
Message-ID: 
 <CAJwFCa2_KofxtqjYRQiPGeeLGBmP0NRqLFzU12uH_s4DOFjfMA@mail.gmail.com>
Subject: Re: Memory leaks in zoo_multi API
To: user@zookeeper.apache.org
Cc: michi@cs.stanford.edu
Content-Type: multipart/alternative; boundary=f46d04447e73b262b904cbe6dd31

--f46d04447e73b262b904cbe6dd31
Content-Type: text/plain; charset=UTF-8

Can you provide sample code and more detailed replication instructions?

On Fri, Oct 12, 2012 at 6:06 PM, Deepak Jagtap <deepak.jagtap@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
> >
>

--f46d04447e73b262b904cbe6dd31--