On Wed, Sep 7, 2016 at 12:24 AM, Oleksandr Natalenko <oleksandr@xxxxxxxxxxxxxx> 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@xxxxxxxx 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@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-users
--
Pranith
_______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
