From: Milian Wolff <milian.wolff@kdab.com>
To: Namhyung Kim <namhyung@kernel.org>
Cc: acme@kernel.org, jolsa@kernel.org,
Jin Yao <yao.jin@linux.intel.com>,
Linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Jiri Olsa <jolsa@redhat.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>,
David Ahern <dsahern@gmail.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
kernel-team@lge.com
Subject: Re: [PATCH v4 05/15] perf report: create real callchain entries for inlined frames
Date: Sun, 08 Oct 2017 22:26:49 +0200 [thread overview]
Message-ID: <1860010.LBD6XXpZyL@agathebauer> (raw)
In-Reply-To: <20171005033529.GB19141@danjae.aot.lge.com>
On Donnerstag, 5. Oktober 2017 05:35:29 CEST Namhyung Kim wrote:
> On Sun, Oct 01, 2017 at 04:30:50PM +0200, Milian Wolff wrote:
> > The inline_node structs are maintained by the new dso->inlines
> > tree. This in turn keeps ownership of the fake symbols and
> > srcline string representing an inline frame.
> >
> > This tree is always sorted by name. All other entries of the symbol
>
> Isn't it sorted by address?
True. The tree of inlines is sorted by address. The sorting by name is part
of a different patch, I'll revise the commit message.
> > beside the function name are unused for inline frames. The advantage
> > of this approach is that all existing users of the callchain API can
> > now transparently display inlined frames without having to patch
> > their code.
> >
> > Cc: Jiri Olsa <jolsa@redhat.com>
> > 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/dso.c | 3 +++
> > tools/perf/util/dso.h | 1 +
> > tools/perf/util/machine.c | 37 ++++++++++++++++++++++++++++++++++
> > tools/perf/util/srcline.c | 51
> > +++++++++++++++++++++++++++++++++++++++++++++++
> > tools/perf/util/srcline.h | 9 +++++++++
> > 5 files changed, 101 insertions(+)
> >
> > diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> > index 339e52971380..6e743dffc487 100644
> > --- a/tools/perf/util/dso.c
> > +++ b/tools/perf/util/dso.c
> > @@ -10,6 +10,7 @@
> >
> > #include "compress.h"
> > #include "path.h"
> > #include "symbol.h"
> >
> > +#include "srcline.h"
> >
> > #include "dso.h"
> > #include "machine.h"
> > #include "auxtrace.h"
> >
> > @@ -1201,6 +1202,7 @@ struct dso *dso__new(const char *name)
> >
> > for (i = 0; i < MAP__NR_TYPES; ++i)
> >
> > dso->symbols[i] = dso->symbol_names[i] = RB_ROOT;
> >
> > dso->data.cache = RB_ROOT;
> >
> > + dso->inlined_nodes = RB_ROOT;
> >
> > dso->data.fd = -1;
> > dso->data.status = DSO_DATA_STATUS_UNKNOWN;
> > dso->symtab_type = DSO_BINARY_TYPE__NOT_FOUND;
> >
> > @@ -1234,6 +1236,7 @@ void dso__delete(struct dso *dso)
> >
> > dso->long_name);
> >
> > for (i = 0; i < MAP__NR_TYPES; ++i)
> >
> > symbols__delete(&dso->symbols[i]);
> >
> > + inlines__tree_delete(&dso->inlined_nodes);
>
> I'm still curious why it doesn't make a trouble (I think there's
> use-after-free for non-inlined symbols). Anyway moving the
> inlines__tree_delete() above the symbols__delete() will solve the
> concern IMHO.
I just tested this again. The reason why I'm not seeing the issue is the
following: The executable DSO is never freed in my case, probably due to a
refcounting bug that is unrelated to the actual patch series here.
Adding some simple debug output to `dso__delete`, I see that it's never being
called for my main executable - only for libraries libm, kernel modules and
pseudo sections like stack/anon/heap etc.
If I'm using a more elaborate example binary with libraries that contain
inlines, I still cannot reproduce an issue with valgrind though...
But with ASAN it finally shows up:
==11080==ERROR: AddressSanitizer: heap-use-after-free on address
0x608000395e4b at pc 0x55a7017388a9 bp 0x7ffe1c99c450 sp 0x7ffe1c99c440
READ of size 1 at 0x608000395e4b thread T0
#0 0x55a7017388a8 in inline_node__delete util/srcline.c:579
#1 0x55a7017388a8 in inlines__tree_delete util/srcline.c:634
#2 0x55a70157c757 in dso__delete util/dso.c:1239
#3 0x55a701614d6b in dsos__purge util/machine.c:139
#4 0x55a701614d6b in dsos__exit util/machine.c:147
#5 0x55a701614d6b in machine__exit util/machine.c:176
#6 0x55a701641ce0 in perf_session__delete util/session.c:203
#7 0x55a70135c50f in cmd_script /home/milian/projects/src/linux/tools/
perf/builtin-script.c:3117
#8 0x55a701472b4c in run_builtin /home/milian/projects/src/linux/tools/
perf/perf.c:296
#9 0x55a70147354a in handle_internal_command /home/milian/projects/src/
linux/tools/perf/perf.c:348
#10 0x55a70128e4c5 in run_argv /home/milian/projects/src/linux/tools/perf/
perf.c:392
#11 0x55a70128e4c5 in main /home/milian/projects/src/linux/tools/perf/
perf.c:536
#12 0x7f402c989f69 in __libc_start_main (/usr/lib/libc.so.6+0x20f69)
#13 0x55a701292989 in _start (/home/milian/projects/src/linux/tools/perf/
perf+0xadd989)
0x608000395e4b is located 43 bytes inside of 86-byte region
[0x608000395e20,0x608000395e76)
freed by thread T0 here:
#0 0x7f40300f2711 in __interceptor_free /build/gcc-multilib/src/gcc/
libsanitizer/asan/asan_malloc_linux.cc:45
#1 0x55a701588a2f in symbol__delete util/symbol.c:282
#2 0x55a701588a2f in symbols__delete util/symbol.c:294
#3 0x55a70157c745 in dso__delete util/dso.c:1238
#4 0x55a701614d6b in dsos__purge util/machine.c:139
#5 0x55a701614d6b in dsos__exit util/machine.c:147
#6 0x55a701614d6b in machine__exit util/machine.c:176
#7 0x55a701641ce0 in perf_session__delete util/session.c:203
#8 0x55a70135c50f in cmd_script /home/milian/projects/src/linux/tools/
perf/builtin-script.c:3117
#9 0x55a701472b4c in run_builtin /home/milian/projects/src/linux/tools/
perf/perf.c:296
#10 0x55a70147354a in handle_internal_command /home/milian/projects/src/
linux/tools/perf/perf.c:348
#11 0x55a70128e4c5 in run_argv /home/milian/projects/src/linux/tools/perf/
perf.c:392
#12 0x55a70128e4c5 in main /home/milian/projects/src/linux/tools/perf/
perf.c:536
#13 0x7f402c989f69 in __libc_start_main (/usr/lib/libc.so.6+0x20f69)
Reordering the statements does fix it, as you suggested.
Many thanks for this review, very valuable!
> > if (dso->short_name_allocated) {
> >
> > zfree((char **)&dso->short_name);
>
> [SNIP]
>
> > diff --git a/tools/perf/util/srcline.c b/tools/perf/util/srcline.c
> > index 07d1a058d7c4..69241d805275 100644
> > --- a/tools/perf/util/srcline.c
> > +++ b/tools/perf/util/srcline.c
> > @@ -583,3 +583,54 @@ void inline_node__delete(struct inline_node *node)
> >
> > free(node);
> >
> > }
> >
> > +
> > +void inlines__tree_insert(struct rb_root *tree, struct inline_node
> > *inlines) +{
> > + struct rb_node **p = &tree->rb_node;
> > + struct rb_node *parent = NULL;
> > + const u64 addr = inlines->addr;
> > + struct inline_node *i;
> > +
> > + while (*p != NULL) {
> > + parent = *p;
> > + i = rb_entry(parent, struct inline_node, rb_node);
> > + if (addr < i->addr)
> > + p = &(*p)->rb_left;
> > + else
> > + p = &(*p)->rb_right;
> > + }
> > + rb_link_node(&inlines->rb_node, parent, p);
> > + rb_insert_color(&inlines->rb_node, tree);
> > +}
> > +
> > +struct inline_node *inlines__tree_find(struct rb_root *tree, u64 addr)
> > +{
> > + struct rb_node *n = tree->rb_node;
> > +
> > + while (n) {
> > + struct inline_node *i = rb_entry(n, struct inline_node,
> > + rb_node);
> > +
> > + if (addr < i->addr)
> > + n = n->rb_left;
> > + else if (addr > i->addr)
> > + n = n->rb_right;
> > + else
> > + return i;
> > + }
> > +
> > + return NULL;
> > +}
> > +
> > +void inlines__tree_delete(struct rb_root *tree)
> > +{
> > + struct inline_node *pos;
> > + struct rb_node *next = rb_first(tree);
> > +
> > + while (next) {
> > + pos = rb_entry(next, struct inline_node, rb_node);
> > + next = rb_next(&pos->rb_node);
> > + rb_erase(&pos->rb_node, tree);
> > + inline_node__delete(pos);
> > + }
> > +}
> > diff --git a/tools/perf/util/srcline.h b/tools/perf/util/srcline.h
> > index 0201ed2c0b9c..ebe38cd22294 100644
> > --- a/tools/perf/util/srcline.h
> > +++ b/tools/perf/util/srcline.h
> > @@ -2,6 +2,7 @@
> >
> > #define PERF_SRCLINE_H
> >
> > #include <linux/list.h>
> >
> > +#include <linux/rbtree.h>
> >
> > #include <linux/types.h>
> >
> > struct dso;
> >
> > @@ -25,6 +26,7 @@ struct inline_list {
> >
> > struct inline_node {
> >
> > u64 addr;
> > struct list_head val;
> >
> > + struct rb_node rb_node;
> >
> > };
> >
> > /* parse inlined frames for the given address */
> >
> > @@ -33,4 +35,11 @@ struct inline_node *dso__parse_addr_inlines(struct dso
> > *dso, u64 addr,>
> > /* free resources associated to the inline node list */
> > void inline_node__delete(struct inline_node *node);
> >
> > +/* insert the inline node list into the DSO, which will take ownership */
> > +void inlines__tree_insert(struct rb_root *tree, struct inline_node
> > *inlines); +/* find previously inserted inline node list */
> > +struct inline_node *inlines__tree_find(struct rb_root *tree, u64 addr);
> > +/* delete all nodes within the tree of inline_node s */
> > +void inlines__tree_delete(struct rb_root *tree);
> > +
> >
> > #endif /* PERF_SRCLINE_H */
--
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
next prev parent reply other threads:[~2017-10-08 20:26 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-10-01 14:30 [PATCH v4 00/15] generate full callchain cursor entries for inlined frames Milian Wolff
2017-10-01 14:30 ` [PATCH v4 01/15] perf report: remove code to handle inline frames from browsers Milian Wolff
2017-10-01 14:30 ` [PATCH v4 02/15] perf util: store srcline in callchain_cursor_node Milian Wolff
2017-10-01 14:30 ` [PATCH v4 03/15] perf util: refactor inline_list to operate on symbols Milian Wolff
2017-10-05 1:56 ` Namhyung Kim
2017-10-08 19:53 ` Milian Wolff
2017-10-01 14:30 ` [PATCH v4 04/15] perf util: refactor inline_list to store srcline string directly Milian Wolff
2017-10-01 14:30 ` [PATCH v4 05/15] perf report: create real callchain entries for inlined frames Milian Wolff
2017-10-05 3:35 ` Namhyung Kim
2017-10-08 20:26 ` Milian Wolff [this message]
2017-10-01 14:30 ` [PATCH v4 06/15] perf report: fall-back to function name comparison for -g srcline Milian Wolff
2017-10-01 14:30 ` [PATCH v4 07/15] perf report: mark inlined frames in output by " (inlined)" suffix Milian Wolff
2017-10-01 14:30 ` [PATCH v4 08/15] perf script: mark inlined frames and do not print DSO for them Milian Wolff
2017-10-01 14:30 ` [PATCH v4 09/15] perf report: compare symbol name for inlined frames when matching Milian Wolff
2017-10-01 14:30 ` [PATCH v4 10/15] perf report: compare symbol name for inlined frames when sorting Milian Wolff
2017-10-01 14:30 ` [PATCH v4 11/15] perf report: properly handle branch count in match_chain Milian Wolff
2017-10-01 14:30 ` [PATCH v4 12/15] perf report: cache failed lookups of inlined frames Milian Wolff
2017-10-05 3:43 ` Namhyung Kim
2017-10-08 20:28 ` Milian Wolff
2017-10-01 14:30 ` [PATCH v4 13/15] perf report: cache srclines for callchain nodes Milian Wolff
2017-10-01 14:30 ` [PATCH v4 14/15] perf report: use srcline from callchain for hist entries Milian Wolff
2017-10-05 4:08 ` Namhyung Kim
2017-10-09 20:21 ` Milian Wolff
2017-10-01 14:31 ` [PATCH v4 15/15] perf util: enable handling of inlined frames by default Milian Wolff
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=1860010.LBD6XXpZyL@agathebauer \
--to=milian.wolff@kdab.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@kernel.org \
--cc=acme@redhat.com \
--cc=dsahern@gmail.com \
--cc=jolsa@kernel.org \
--cc=jolsa@redhat.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).