linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Milian Wolff <milian.wolff@kdab.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: Linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
	Arnaldo Carvalho de Melo <acme@redhat.com>,
	David Ahern <dsahern@gmail.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Yao Jin <yao.jin@linux.intel.com>,
	kernel-team@lge.com
Subject: Re: [PATCH] perf report: fix memory leak in addr2line when called by addr2inlines
Date: Wed, 17 May 2017 10:03:38 +0200	[thread overview]
Message-ID: <5519627.MtzUhqv9sX@milian-kdab2> (raw)
In-Reply-To: <20170517042049.GA32691@danjae.aot.lge.com>

[-- Attachment #1: Type: text/plain, Size: 4107 bytes --]

On Wednesday, May 17, 2017 6:20:49 AM CEST Namhyung Kim wrote:
> On Tue, May 16, 2017 at 11:53:59PM +0200, Milian Wolff wrote:
> > When a filename was found in addr2line it was duplicated via strdup
> > but never freed. Now we pass NULL and handle this gracefully in
> > addr2line.
> > 
> > Detected by Valgrind:
> > 
> > ==16331== 1,680 bytes in 21 blocks are definitely lost in loss record 148
> > of 220 ==16331==    at 0x4C2AF1F: malloc (in
> > /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==16331==    by
> > 0x672FA69: strdup (in /usr/lib/libc-2.25.so)
> > ==16331==    by 0x52769F: addr2line (srcline.c:256)
> > ==16331==    by 0x52769F: addr2inlines (srcline.c:294)
> > ==16331==    by 0x52769F: dso__parse_addr_inlines (srcline.c:502)
> > ==16331==    by 0x574D7A: inline__fprintf (hist.c:41)
> > ==16331==    by 0x574D7A: ipchain__fprintf_graph (hist.c:147)
> > ==16331==    by 0x57518A: __callchain__fprintf_graph (hist.c:212)
> > ==16331==    by 0x5753CF: callchain__fprintf_graph.constprop.6
> > (hist.c:337)
> > ==16331==    by 0x57738E: hist_entry__fprintf (hist.c:628)
> > ==16331==    by 0x57738E: hists__fprintf (hist.c:882)
> > ==16331==    by 0x44A20F: perf_evlist__tty_browse_hists
> > (builtin-report.c:399) ==16331==    by 0x44A20F: report__browse_hists
> > (builtin-report.c:491) ==16331==    by 0x44A20F: __cmd_report
> > (builtin-report.c:624)
> > ==16331==    by 0x44A20F: cmd_report (builtin-report.c:1054)
> > ==16331==    by 0x4A49CE: run_builtin (perf.c:296)
> > ==16331==    by 0x4A4CC0: handle_internal_command (perf.c:348)
> > ==16331==    by 0x434371: run_argv (perf.c:392)
> > ==16331==    by 0x434371: main (perf.c:530)
> > 
> > Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
> > Cc: David Ahern <dsahern@gmail.com>
> > Cc: Namhyung Kim <namhyung@kernel.org>
> > Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Cc: Yao Jin <yao.jin@linux.intel.com>
> > Signed-off-by: Milian Wolff <milian.wolff@kdab.com>
> > ---
> > 
> >  tools/perf/util/srcline.c | 13 ++++++-------
> >  1 file changed, 6 insertions(+), 7 deletions(-)
> > 
> > diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> > index df051a52393c..62cf42c36955 100644
> > --- a/tools/perf/util/srcline.c
> > +++ b/tools/perf/util/srcline.c
> > @@ -253,10 +253,11 @@ static int addr2line(const char *dso_name, u64 addr,
> > 
> >  	}
> >  	
> >  	if (a2l->found && a2l->filename) {
> 
> Not related, but I think it'd be better checking "a2l->found" after
> bfd_map_over_sections() and bail out if not.

OK, can do.

> > -		*file = strdup(a2l->filename);
> > -		*line = a2l->line;
> > -
> > -		if (*file)
> > +		if (file)
> > +			*file = strdup(a2l->filename);
> > +		if (line)
> > +			*line = a2l->line;
> > +		if (*a2l->filename)
> 
> Didn't you want to check a2l->filename being non-NULL instead?  And if
> so, this can be :

I just ported the old code, which basically did:

> > -		*file = strdup(a2l->filename);
> > -		if (*file)

So now I inlined the `a2l->filename` to get (close) to the original behavior. 
I just realize the return value would be different now if `file != NULL` and 
strdup failed. I will look into that again.

> 		if (!file || *file)
> 
> >  			ret = 1;
> >  	
> >  	}
> 
> Thanks,
> Namhyung
> 
> > @@ -278,8 +279,6 @@ void dso__free_a2l(struct dso *dso)
> > 
> >  static struct inline_node *addr2inlines(const char *dso_name, u64 addr,
> >  
> >  	struct dso *dso)
> >  
> >  {
> > 
> > -	char *file = NULL;
> > -	unsigned int line = 0;
> > 
> >  	struct inline_node *node;
> >  	
> >  	node = zalloc(sizeof(*node));
> > 
> > @@ -291,7 +290,7 @@ static struct inline_node *addr2inlines(const char
> > *dso_name, u64 addr,> 
> >  	INIT_LIST_HEAD(&node->val);
> >  	node->addr = addr;
> > 
> > -	if (!addr2line(dso_name, addr, &file, &line, dso, TRUE, node))
> > +	if (!addr2line(dso_name, addr, NULL, NULL, dso, TRUE, node))
> > 
> >  		goto out_free_inline_node;
> >  	
> >  	if (list_empty(&node->val))


-- 
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]

      reply	other threads:[~2017-05-17  8:03 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-16 21:53 [PATCH] perf report: fix memory leak in addr2line when called by addr2inlines Milian Wolff
2017-05-17  4:20 ` Namhyung Kim
2017-05-17  8:03   ` Milian Wolff [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5519627.MtzUhqv9sX@milian-kdab2 \
    --to=milian.wolff@kdab.com \
    --cc=Linux-kernel@vger.kernel.org \
    --cc=a.p.zijlstra@chello.nl \
    --cc=acme@redhat.com \
    --cc=dsahern@gmail.com \
    --cc=kernel-team@lge.com \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=namhyung@kernel.org \
    --cc=yao.jin@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).