Correct. On September 7, 2016 1:51:08 AM GMT+03:00, Pranith Kumar Karampuri <pkarampu@xxxxxxxxxx> wrote: >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 >> _______________________________________________ Gluster-users mailing list Gluster-users@xxxxxxxxxxx http://www.gluster.org/mailman/listinfo/gluster-users
