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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.