Received: by 2002:ac0:b08d:0:0:0:0:0 with SMTP id l13csp4488416imc; Mon, 25 Feb 2019 05:55:24 -0800 (PST) X-Google-Smtp-Source: AHgI3IZ+cmvzbkG+7Pmye5RC8Xolv+hYy7DC4dWjw09lUQxcy6erol6GxyZfORy/Ykx4rRj68Sxv X-Received: by 2002:a17:902:1122:: with SMTP id d31mr20581275pla.246.1551102924815; Mon, 25 Feb 2019 05:55:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551102924; cv=none; d=google.com; s=arc-20160816; b=uot/+Ygx+grNwIsDL2vzefBvVXiUZ9s8siBhfitaiord+YQVbPuCrqbwVHWlVssSEW JFeJTNsGi5aD2QsVZWQRnhTT/X3NEaMVDnGswJITnwx7nBXZz/D11sFZQvidrlU6W+cS HtoCwRTmkBLx/6MVvT5Ln33XNEhPD9VhJNxdhzucQtws1UvsBjf0+G0tAxFs6dEUKCsJ KEn2mp22jkrAWGtw7bfATPZ+5gZuTj6CrbcPFjVKw72g09i4W4bC9tFdLwe5ODHMU0d6 BNEqdZjrXR/XVUa3NG2VOKj8JmId/SvPuma6O9zu/5draHMjQcnHgB6vHjEGp6XE2jlO bGYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=jwIk44b5opcWW3tFbNNRyQ87U1mJnB5RXgSfyTawmlA=; b=W3TMcPpYNx3Uk1j6jiOIc5uFgl/cMbZCq+MLUWxWSmafoddgWItD6dWfjjPRkf5y7k 1uwv9OQk1DwBYNZkg2hRHSOc+3lug8LIo+k6Z8K2bvVNy9i773Lot2FVx4VIsx7o2Mue 3M36+mJ0H5/z/JUS8X37FxZzFSs6HreI6jdx+kEP71pKlAJSeqHx1rBRQhK5tjnNsEMp G3vRjgS8es0rCpAbdVYD990shWWdEYHpcxTLK9BZEwTgkVc3kwFfQNGjvWSPu/+ZmNEd P7ZSXl9rqv1R0Y9NmMCUOMjDBzJe3thBSO66uuxgRzYUq5T7unIG9LdKcCbs5lRLMLm2 lRkA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f10si10763062pfh.8.2019.02.25.05.55.08; Mon, 25 Feb 2019 05:55:24 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726706AbfBYNyf (ORCPT + 99 others); Mon, 25 Feb 2019 08:54:35 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49438 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725990AbfBYNye (ORCPT ); Mon, 25 Feb 2019 08:54:34 -0500 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 212748667D; Mon, 25 Feb 2019 13:54:34 +0000 (UTC) Received: from krava (unknown [10.43.17.18]) by smtp.corp.redhat.com (Postfix) with SMTP id 3C6AA5D9D1; Mon, 25 Feb 2019 13:54:32 +0000 (UTC) Date: Mon, 25 Feb 2019 14:54:30 +0100 From: Jiri Olsa To: Namhyung Kim Cc: Jonas Rabenstein , linux-perf-users , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo , Alexander Shishkin , linux-kernel Subject: Re: [PATCH] perf hist: fix memory leak if histogram entry is reused Message-ID: <20190225135430.GD14757@krava> References: <20190221122306.1511-1-jonas.rabenstein@studium.uni-erlangen.de> <20190221123909.GG10990@krava> <20190221135320.io7egcwajehfrdd5@studium.uni-erlangen.de> <20190221162858.GA3940@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Mon, 25 Feb 2019 13:54:34 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, Feb 23, 2019 at 12:18:18PM +0900, Namhyung Kim wrote: > Hi, > > On Fri, Feb 22, 2019 at 1:29 AM Jiri Olsa wrote: > > > > On Thu, Feb 21, 2019 at 02:53:20PM +0100, Jonas Rabenstein wrote: > > > On Thu, Feb 21, 2019 at 01:39:09PM +0100, Jiri Olsa wrote: > > > > On Thu, Feb 21, 2019 at 01:23:06PM +0100, Jonas Rabenstein wrote: > > > > > In __hists__add_entry the srcline of the addr_location is duplicated > > > > > for the hist_entry. If hists__findnew_entry returns an already existing > > > > > hist_entry the srcline has to be freed again as no further reference to > > > > > that duplicated srcline would exists anymore. > > > > > > > > > > Signed-off-by: Jonas Rabenstein > > > > > --- > > > > > tools/perf/util/hist.c | 3 +++ > > > > > 1 file changed, 3 insertions(+) > > > > > > > > > > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c > > > > > index 8aad8330e392..25b8dbdbbe87 100644 > > > > > --- a/tools/perf/util/hist.c > > > > > +++ b/tools/perf/util/hist.c > > > > > @@ -623,6 +623,9 @@ __hists__add_entry(struct hists *hists, > > > > > .ops = ops, > > > > > }, *he = hists__findnew_entry(hists, &entry, al, sample_self); > > > > > > > > > > + if (he && he->srcline != entry.srcline) > > > > > + free(entry.srcline); > > > > > + > > > > > if (!hists->has_callchains && he && he->callchain_size != 0) > > > > > hists->has_callchains = true; > > > > > return he; > > > > > > > > nice, do we have similar issue in here? > > > > > > > > jirka > > > > > > > > > > > > --- > > > > diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c > > > > index 216388003dea..e65e6822c848 100644 > > > > --- a/tools/perf/util/hist.c > > > > +++ b/tools/perf/util/hist.c > > > > @@ -966,7 +966,7 @@ iter_add_next_cumulative_entry(struct hist_entry_iter *iter, > > > > .map = al->map, > > > > .sym = al->sym, > > > > }, > > > > - .srcline = al->srcline ? strdup(al->srcline) : NULL, > > > > + .srcline = al->srcline, > > > While this shouldn't leak the memory, we may end up with an al->srcline > > > to get free afterwards while still having a reference on it within the > > > hist_entry... Also I could not find where/how the hist_entry is freed up > > > so we may get an double free if both of al and he clean the srcline. > > > Of course, with your solution we could spare the useless strdup/free if > > > we find an hist_entry (which should be the typical case for hotspots..). > > > Taking a deeper look thus should be beneficial - but I do not have the > > > time for that right now because I'm still working on the inline-symbol > > > integration which is more important for me... > > > > ok, I'll check it > > I think we can defer calling strdup() to hist_entry__init(). right, thats actualy better fix even for the original patch, I'll try to post it soon thanks, jirka