<div dir="ltr"><div><div>+Prasanna<br><br></div>Prasanna changed qemu code to reuse the glfs object for adding multiple disks from same volume using refcounting. So the memory usage went down from 2GB to 200MB in the case he targetted. Wondering if the same can be done for this case too.<br><br></div>Prasanna could you let us know if we can use refcounting even in this case.<br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Sep 7, 2016 at 10:28 AM, Oleksandr Natalenko <span dir="ltr"><<a href="mailto:oleksandr@natalenko.name" target="_blank">oleksandr@natalenko.name</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Correct.<br>
<div class="HOEnZb"><div class="h5"><br>
On September 7, 2016 1:51:08 AM GMT+03:00, Pranith Kumar Karampuri <<a href="mailto:pkarampu@redhat.com">pkarampu@redhat.com</a>> wrote:<br>
>On Wed, Sep 7, 2016 at 12:24 AM, Oleksandr Natalenko <<br>
><a href="mailto:oleksandr@natalenko.name">oleksandr@natalenko.name</a>> wrote:<br>
><br>
>> Hello,<br>
>><br>
>> thanks, but that is not what I want. I have no issues debugging gfapi<br>
>apps,<br>
>> but have an issue with GlusterFS FUSE client not being handled<br>
>properly by<br>
>> Massif tool.<br>
>><br>
>> Valgrind+Massif does not handle all forked children properly, and I<br>
>believe<br>
>> that happens because of some memory corruption in GlusterFS FUSE<br>
>client.<br>
>><br>
><br>
>Is this the same libc issue that we debugged and provided with the<br>
>option<br>
>to avoid it?<br>
><br>
><br>
>><br>
>> Regards,<br>
>> Oleksandr<br>
>><br>
>> On субота, 3 вересня 2016 р. 18:21:59 EEST <a href="mailto:feihu929@sina.com">feihu929@sina.com</a> wrote:<br>
>> > Hello, Oleksandr<br>
>> > You can compile that simple test code posted<br>
>> > here(<a href="http://www.gluster.org/pipermail/gluster-users/2016-" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>pipermail/gluster-users/2016-</a><br>
>> August/028183.html<br>
>> > ). Then, run the command<br>
>> > $>valgrind cmd: G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind<br>
>> > --tool=massif ./glfsxmp the cmd will produce a file like<br>
>> massif.out.xxxx,<br>
>> > the file is the memory leak log file , you can use ms_print tool<br>
>as<br>
>> below<br>
>> > command $>ms_print massif.out.xxxx<br>
>> > the cmd will output the memory alloc detail.<br>
>> ><br>
>> > the simple test code just call glfs_init and glfs_fini 100 times to<br>
>found<br>
>> > the memory leak, by my test, all xlator init and fini is the main<br>
>memory<br>
>> > leak function. If you can locate the simple code memory leak code,<br>
>maybe,<br>
>> > you can locate the leak code in fuse client.<br>
>> ><br>
>> > please enjoy.<br>
>><br>
>><br>
>> ______________________________<wbr>_________________<br>
>> Gluster-users mailing list<br>
>> <a href="mailto:Gluster-users@gluster.org">Gluster-users@gluster.org</a><br>
>> <a href="http://www.gluster.org/mailman/listinfo/gluster-users" rel="noreferrer" target="_blank">http://www.gluster.org/<wbr>mailman/listinfo/gluster-users</a><br>
>><br>
<br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Pranith<br></div></div>
</div>