<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:宋体;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@宋体";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"\@等线";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"Segoe UI";
panose-1:2 11 5 2 4 2 4 2 2 3;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:宋体;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:宋体;}
p.m6585033272108786365m-3400543437059354645msolistparagraph, li.m6585033272108786365m-3400543437059354645msolistparagraph, div.m6585033272108786365m-3400543437059354645msolistparagraph
{mso-style-name:m_6585033272108786365m_-3400543437059354645msolistparagraph;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:12.0pt;
font-family:宋体;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:DengXian;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:DengXian;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:DengXian">HI,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:DengXian"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:DengXian">I think I find another suspicious memory leak.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:DengXian">In function
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1A1A1A">vasprintf, the memory is allocated by GF_ALLOC, but when free this memory, it is not by GF_FREE , instead, it is freed by FREE or free. This will make memory
accounting not accurate, also will have some memory lost. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1A1A1A">There are many log interfaces in logging.c<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1A1A1A">Anyone know why the memory is not freed by GF_FREE ?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1A1A1A">I see following explanation from _gf_log_eh<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.0pt;font-family:"Segoe UI",sans-serif;color:#1A1A1A">/* Use FREE instead of GF_FREE since str2 was allocated by vasprintf */<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:DengXian">but why ?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:10.5pt;font-family:DengXian"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Atin Mukherjee [mailto:amukherj@redhat.com]
<br>
<b>Sent:</b> Tuesday, February 27, 2018 10:37 AM<br>
<b>To:</b> Raghavendra Gowdappa <rgowdapp@redhat.com>; Gaurav Yadav <gyadav@redhat.com><br>
<b>Cc:</b> Storage, Dev (Nokia - Global) <dev.storage@nokia.com>; Csaba Henk <chenk@redhat.com>; gluster-devel@gluster.org; Madappa, Kaushal <kmadappa@redhat.com><br>
<b>Subject:</b> Re: two potential memory leak place found on glusterfs 3.12.3<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">+Gaurav<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Mon, Feb 26, 2018 at 2:02 PM, Raghavendra Gowdappa <<a href="mailto:rgowdapp@redhat.com" target="_blank">rgowdapp@redhat.com</a>> wrote:<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<p class="MsoNormal"><span lang="EN-US">+glusterd devs<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Mon, Feb 26, 2018 at 1:41 PM, Storage, Dev (Nokia - Global) <<a href="mailto:dev.storage@nokia.com" target="_blank">dev.storage@nokia.com</a>> wrote:<o:p></o:p></span></p>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Hi glusterfs experts,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> Good day!<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> During our recent test we found that after execute some glusterfs command, there are obvious memory leak found for glusterd process, when we compare statedump
of glusterd process before and after command executions.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">
<o:p></o:p></span></p>
<p class="m6585033272108786365m-3400543437059354645msolistparagraph" style="margin-left:33.6pt">
<span lang="EN-US">1></span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span lang="EN-US">Each time of command </span>“<span lang="EN-US">gluster volume list</span>”<span lang="EN-US"> command there are some memory lost from section [mgmt/glusterd.management - usage-type gf_common_mt_char memusage] in glusterd statedump,
after investigation, we found that <o:p></o:p></span></p>
<p class="m6585033272108786365m-3400543437059354645msolistparagraph" style="margin-left:33.6pt">
<span lang="EN-US">For __glusterd_handle_cli_list_volume , after glusterd_submit_reply, should free rsp.dict.dict_val.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US"> This needs to be looked at.<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="m6585033272108786365m-3400543437059354645msolistparagraph" style="margin-left:33.6pt">
<span lang="EN-US">2></span><span lang="EN-US" style="font-size:7.0pt;font-family:"Times New Roman",serif">
</span><span lang="EN-US">Each time of command </span>“<span lang="EN-US">gluster volume status <volume name></span>”<span lang="EN-US"> command there are some memory lost from section mgmt/glusterd.management - usage-type gf_common_mt_strdup memusage in glusterd
statedump, after investigation, we found that<o:p></o:p></span></p>
<p class="m6585033272108786365m-3400543437059354645msolistparagraph" style="margin-left:33.6pt">
<span lang="EN-US">For glusterd_mgmt_v3_unlock, before gf_timer_call_cancel, should free pointer
</span>“<span lang="EN-US">data</span>”<span lang="EN-US"> in mgmt_lock_timer->timer.<o:p></o:p></span></p>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">Gaurav is working on a patch where this has been already identified. So the analysis on point 2 seems to be correct.<br>
<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm">
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:21.0pt">
<span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:21.0pt">
<span lang="EN-US">Could you help to comment on the above two findings? Thanks!<o:p></o:p></span></p>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</div>
</div>
</div>
</body>
</html>