[Gluster-users] Gfapi memleaks, all versions

[Pranith Kumar Karampuri]

On Wed, Sep 7, 2016 at 12:24 AM, Oleksandr Natalenko <
oleksandr at natalenko.name> wrote:

> Hello,
>
> thanks, but that is not what I want. I have no issues debugging gfapi apps,
> but have an issue with GlusterFS FUSE client not being handled properly by
> Massif tool.
>
> Valgrind+Massif does not handle all forked children properly, and I believe
> that happens because of some memory corruption in GlusterFS FUSE client.
>

Is this the same libc issue that we debugged and provided with the option
to avoid it?


>
> Regards,
>   Oleksandr
>
> On субота, 3 вересня 2016 р. 18:21:59 EEST feihu929 at sina.com wrote:
> >  Hello,  Oleksandr
> >     You can compile that simple test code posted
> > here(http://www.gluster.org/pipermail/gluster-users/2016-
> August/028183.html
> > ). Then, run the command
> > $>valgrind cmd: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind
> > --tool=massif  ./glfsxmp the cmd will produce a file like
> massif.out.xxxx,
> >  the file is the memory leak log file , you can use ms_print tool as
> below
> > command $>ms_print  massif.out.xxxx
> > the cmd will output the memory alloc detail.
> >
> > the simple test code just call glfs_init and glfs_fini 100 times to found
> > the memory leak,  by my test, all xlator init and fini is the main memory
> > leak function. If you can locate the simple code memory leak code, maybe,
> > you can locate the leak code in fuse client.
> >
> > please enjoy.
>
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-users
>



-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-users/attachments/20160907/f04af00f/attachment.html>