Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1255898 > unrolled thread
| Started by | Jiri Olsa <jolsa@redhat.com> |
|---|---|
| First post | 2015-10-26 14:10 +0100 |
| Last post | 2015-10-29 10:50 +0100 |
| Articles | 4 — 3 participants |
Back to article view | Back to linux.kernel
[BUG] reporting stuck on s390 in dso__split_kallsyms_for_kcore Jiri Olsa <jolsa@redhat.com> - 2015-10-26 14:10 +0100
Re: [BUG] reporting stuck on s390 in dso__split_kallsyms_for_kcore Adrian Hunter <adrian.hunter@intel.com> - 2015-10-26 14:30 +0100
[PATCH] perf tools: Fix endless loop in dso__split_kallsyms_for_kcore Jiri Olsa <jolsa@redhat.com> - 2015-10-26 15:00 +0100
[tip:perf/core] perf symbols: Fix endless loop in dso__split_kallsyms_for_kcore tip-bot for Jiri Olsa <tipbot@zytor.com> - 2015-10-29 10:50 +0100
| From | Jiri Olsa <jolsa@redhat.com> |
|---|---|
| Date | 2015-10-26 14:10 +0100 |
| Subject | [BUG] reporting stuck on s390 in dso__split_kallsyms_for_kcore |
| Message-ID | <qnPHe-cN-97@gated-at.bofh.it> |
hi,
I'm getting stuck buildid-list command on s390
seems like the kcore code gets stuck with inseting
into rbtree while iterating it..
I was able to fix it with patch below, bu I'm not sure it's the
correct fix because the kcore maps magic is beyond me so far ;-)
please check attached backtrace and patch
(gdb) r buildid-list -i perf.data --with-hits
Starting program: /root/linux/tools/perf/./perf buildid-list -i perf.data --with-hits
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 56723.
^C
Program received signal SIGINT, Interrupt.
rb_next (node=0x81573930, node@entry=0x81551840) at ../lib/rbtree.c:451
451 node=node->rb_left;
Missing separate debuginfos, use: debuginfo-install audit-libs-2.4.1-5.el7.s390x bzip2-libs-1.0.6-13.el7.s390x elfutils-libelf-0.163-3.el7.s390x elfutils-libs-0.163-3.el7.s390x glibc-2.17-105.el7.s390x nss-softokn-freebl-3.16.2.3-13.el7_1.s390x perl-libs-5.16.3-286.el7.s390x python-libs-2.7.5-34.el7.s390x slang-2.2.4-11.el7.s390x xz-libs-5.1.2-12alpha.el7.s390x zlib-1.2.7-15.el7.s390x
(gdb) bt
#0 rb_next (node=0x81573930, node@entry=0x81551840) at ../lib/rbtree.c:451
#1 0x00000000800a7da0 in dso__split_kallsyms_for_kcore (dso=dso@entry=0x812e69c0, map=map@entry=0x812e6fb0, filter=filter@entry=0x0)
at util/symbol.c:668
#2 0x00000000800a9ac6 in dso__load_kallsyms (dso=dso@entry=0x812e69c0, filename=filename@entry=0x81353030 "/proc/kallsyms",
map=map@entry=0x812e6fb0, filter=filter@entry=0x0) at util/symbol.c:1289
#3 0x00000000800aa0c4 in dso__load_kernel_sym (dso=dso@entry=0x812e69c0, map=map@entry=0x812e6fb0, filter=filter@entry=0x0)
at util/symbol.c:1783
#4 0x00000000800aa208 in dso__load (dso=0x812e69c0, map=map@entry=0x812e6fb0, filter=filter@entry=0x0) at util/symbol.c:1420
#5 0x00000000800bb2aa in map__load (map=0x812e6fb0, filter=0x0) at util/map.c:289
#6 0x0000000080087c9e in thread__find_addr_map (thread=<optimized out>, cpumode=cpumode@entry=1 '\001', type=type@entry=MAP__FUNCTION,
addr=<optimized out>, al=al@entry=0x3ffffffe118) at util/event.c:969
#7 0x0000000080081908 in build_id__mark_dso_hit (tool=<optimized out>, event=0x3fffd5aa568, sample=0x3ffffffe410, evsel=<optimized out>,
machine=<optimized out>) at util/build-id.c:41
#8 0x00000000800bdfec in perf_evlist__deliver_sample (evlist=evlist@entry=0x812e5d60,
tool=tool@entry=0x8024b240 <build_id__mark_dso_hit_ops>, event=event@entry=0x3fffd5aa568, sample=sample@entry=0x3ffffffe410,
evsel=evsel@entry=0x812e6770, machine=0x812e5ab8) at util/session.c:1039
#9 0x00000000800be156 in machines__deliver_event (machines=machines@entry=0x812e5ab8, evlist=0x812e5d60,
event=event@entry=0x3fffd5aa568, sample=sample@entry=0x3ffffffe410, tool=tool@entry=0x8024b240 <build_id__mark_dso_hit_ops>,
file_offset=136552) at util/session.c:1076
#10 0x00000000800be3f2 in perf_session__deliver_event (session=session@entry=0x812e59e0, event=event@entry=0x3fffd5aa568,
sample=sample@entry=0x3ffffffe410, tool=tool@entry=0x8024b240 <build_id__mark_dso_hit_ops>, file_offset=<optimized out>)
at util/session.c:1133
#11 0x00000000800c0146 in perf_session__process_event (session=session@entry=0x812e59e0, event=event@entry=0x3fffd5aa568,
file_offset=file_offset@entry=136552) at util/session.c:1298
#12 0x00000000800c0746 in __perf_session__process_events (session=session@entry=0x812e59e0, data_offset=<optimized out>,
data_size=<optimized out>, file_size=1164232, file_size@entry=1166128) at util/session.c:1633
#13 0x00000000800c0c2c in perf_session__process_events (session=session@entry=0x812e59e0) at util/session.c:1683
#14 0x000000008002ae5e in perf_session__list_build_ids (force=<optimized out>, with_hits=true) at builtin-buildid-list.c:82
#15 0x000000008002b078 in cmd_buildid_list (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>)
at builtin-buildid-list.c:115
#16 0x000000008007c71a in run_builtin (p=p@entry=0x8024aab8 <commands+24>, argc=argc@entry=4, argv=0x3fffffff090) at perf.c:385
#17 0x000000008007c95e in handle_internal_command (argc=<optimized out>, argv=<optimized out>) at perf.c:445
#18 0x000000008007c9e4 in run_argv (argcp=argcp@entry=0x3ffffffedd4, argv=argv@entry=0x3ffffffedc8) at perf.c:489
#19 0x000000008007cca2 in main (argc=4, argv=0x3fffffff090) at perf.c:606
thanks,
jirka
---
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e7bf0c4..b0d2fb2 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -680,7 +680,7 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso, struct map *map,
pos->start -= curr_map->start - curr_map->pgoff;
if (pos->end)
pos->end -= curr_map->start - curr_map->pgoff;
- if (curr_map != map) {
+ if (curr_map->dso != map->dso) {
rb_erase_init(&pos->rb_node, root);
symbols__insert(
&curr_map->dso->symbols[curr_map->type],
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Adrian Hunter <adrian.hunter@intel.com> |
|---|---|
| Date | 2015-10-26 14:30 +0100 |
| Message-ID | <qnQ0x-jm-5@gated-at.bofh.it> |
| In reply to | #1255898 |
[Multipart message — attachments visible in raw view] — view raw
On 26/10/15 15:01, Jiri Olsa wrote:
> hi,
> I'm getting stuck buildid-list command on s390
>
> seems like the kcore code gets stuck with inseting
> into rbtree while iterating it..
>
> I was able to fix it with patch below, bu I'm not sure it's the
> correct fix because the kcore maps magic is beyond me so far ;-)
>
> please check attached backtrace and patch
Your fix looks correct to me.
>
>
> (gdb) r buildid-list -i perf.data --with-hits
By the way, there are problems with buildid-list, I have the patches
attached but haven't had a chance to send them. If you find are missing
buildids you might want to try them.
> Starting program: /root/linux/tools/perf/./perf buildid-list -i perf.data --with-hits
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib64/libthread_db.so.1".
> Detaching after fork from child process 56723.
> ^C
> Program received signal SIGINT, Interrupt.
> rb_next (node=0x81573930, node@entry=0x81551840) at ../lib/rbtree.c:451
> 451 node=node->rb_left;
> Missing separate debuginfos, use: debuginfo-install audit-libs-2.4.1-5.el7.s390x bzip2-libs-1.0.6-13.el7.s390x elfutils-libelf-0.163-3.el7.s390x elfutils-libs-0.163-3.el7.s390x glibc-2.17-105.el7.s390x nss-softokn-freebl-3.16.2.3-13.el7_1.s390x perl-libs-5.16.3-286.el7.s390x python-libs-2.7.5-34.el7.s390x slang-2.2.4-11.el7.s390x xz-libs-5.1.2-12alpha.el7.s390x zlib-1.2.7-15.el7.s390x
> (gdb) bt
> #0 rb_next (node=0x81573930, node@entry=0x81551840) at ../lib/rbtree.c:451
> #1 0x00000000800a7da0 in dso__split_kallsyms_for_kcore (dso=dso@entry=0x812e69c0, map=map@entry=0x812e6fb0, filter=filter@entry=0x0)
> at util/symbol.c:668
> #2 0x00000000800a9ac6 in dso__load_kallsyms (dso=dso@entry=0x812e69c0, filename=filename@entry=0x81353030 "/proc/kallsyms",
> map=map@entry=0x812e6fb0, filter=filter@entry=0x0) at util/symbol.c:1289
> #3 0x00000000800aa0c4 in dso__load_kernel_sym (dso=dso@entry=0x812e69c0, map=map@entry=0x812e6fb0, filter=filter@entry=0x0)
> at util/symbol.c:1783
> #4 0x00000000800aa208 in dso__load (dso=0x812e69c0, map=map@entry=0x812e6fb0, filter=filter@entry=0x0) at util/symbol.c:1420
> #5 0x00000000800bb2aa in map__load (map=0x812e6fb0, filter=0x0) at util/map.c:289
> #6 0x0000000080087c9e in thread__find_addr_map (thread=<optimized out>, cpumode=cpumode@entry=1 '\001', type=type@entry=MAP__FUNCTION,
> addr=<optimized out>, al=al@entry=0x3ffffffe118) at util/event.c:969
> #7 0x0000000080081908 in build_id__mark_dso_hit (tool=<optimized out>, event=0x3fffd5aa568, sample=0x3ffffffe410, evsel=<optimized out>,
> machine=<optimized out>) at util/build-id.c:41
> #8 0x00000000800bdfec in perf_evlist__deliver_sample (evlist=evlist@entry=0x812e5d60,
> tool=tool@entry=0x8024b240 <build_id__mark_dso_hit_ops>, event=event@entry=0x3fffd5aa568, sample=sample@entry=0x3ffffffe410,
> evsel=evsel@entry=0x812e6770, machine=0x812e5ab8) at util/session.c:1039
> #9 0x00000000800be156 in machines__deliver_event (machines=machines@entry=0x812e5ab8, evlist=0x812e5d60,
> event=event@entry=0x3fffd5aa568, sample=sample@entry=0x3ffffffe410, tool=tool@entry=0x8024b240 <build_id__mark_dso_hit_ops>,
> file_offset=136552) at util/session.c:1076
> #10 0x00000000800be3f2 in perf_session__deliver_event (session=session@entry=0x812e59e0, event=event@entry=0x3fffd5aa568,
> sample=sample@entry=0x3ffffffe410, tool=tool@entry=0x8024b240 <build_id__mark_dso_hit_ops>, file_offset=<optimized out>)
> at util/session.c:1133
> #11 0x00000000800c0146 in perf_session__process_event (session=session@entry=0x812e59e0, event=event@entry=0x3fffd5aa568,
> file_offset=file_offset@entry=136552) at util/session.c:1298
> #12 0x00000000800c0746 in __perf_session__process_events (session=session@entry=0x812e59e0, data_offset=<optimized out>,
> data_size=<optimized out>, file_size=1164232, file_size@entry=1166128) at util/session.c:1633
> #13 0x00000000800c0c2c in perf_session__process_events (session=session@entry=0x812e59e0) at util/session.c:1683
> #14 0x000000008002ae5e in perf_session__list_build_ids (force=<optimized out>, with_hits=true) at builtin-buildid-list.c:82
> #15 0x000000008002b078 in cmd_buildid_list (argc=<optimized out>, argv=<optimized out>, prefix=<optimized out>)
> at builtin-buildid-list.c:115
> #16 0x000000008007c71a in run_builtin (p=p@entry=0x8024aab8 <commands+24>, argc=argc@entry=4, argv=0x3fffffff090) at perf.c:385
> #17 0x000000008007c95e in handle_internal_command (argc=<optimized out>, argv=<optimized out>) at perf.c:445
> #18 0x000000008007c9e4 in run_argv (argcp=argcp@entry=0x3ffffffedd4, argv=argv@entry=0x3ffffffedc8) at perf.c:489
> #19 0x000000008007cca2 in main (argc=4, argv=0x3fffffff090) at perf.c:606
>
>
> thanks,
> jirka
>
>
> ---
> diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
> index e7bf0c4..b0d2fb2 100644
> --- a/tools/perf/util/symbol.c
> +++ b/tools/perf/util/symbol.c
> @@ -680,7 +680,7 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso, struct map *map,
> pos->start -= curr_map->start - curr_map->pgoff;
> if (pos->end)
> pos->end -= curr_map->start - curr_map->pgoff;
> - if (curr_map != map) {
> + if (curr_map->dso != map->dso) {
> rb_erase_init(&pos->rb_node, root);
> symbols__insert(
> &curr_map->dso->symbols[curr_map->type],
>
[toc] | [prev] | [next] | [standalone]
| From | Jiri Olsa <jolsa@redhat.com> |
|---|---|
| Date | 2015-10-26 15:00 +0100 |
| Subject | [PATCH] perf tools: Fix endless loop in dso__split_kallsyms_for_kcore |
| Message-ID | <qnQtC-ue-59@gated-at.bofh.it> |
| In reply to | #1255905 |
On Mon, Oct 26, 2015 at 03:22:33PM +0200, Adrian Hunter wrote:
> On 26/10/15 15:01, Jiri Olsa wrote:
> > hi,
> > I'm getting stuck buildid-list command on s390
> >
> > seems like the kcore code gets stuck with inseting
> > into rbtree while iterating it..
> >
> > I was able to fix it with patch below, bu I'm not sure it's the
> > correct fix because the kcore maps magic is beyond me so far ;-)
> >
> > please check attached backtrace and patch
>
> Your fix looks correct to me.
great, attached patch with changelog.. please
feel free to add more detail or correct it
thanks,
jirka
---
Currently we split symbols based on the map comparison,
but symbols are stored within dso objects and maps could
point into same dso objects (kernel maps).
Hence we could end up changing rbtree we are currently
iterating and mess it up. It's easily reproduced on
s390x by running:
$ perf record -a -- sleep 3
$ perf buildid-list -i perf.data --with-hits
The fix is to compare dso objects instead.
Reported-by: Michael Petlan <mpetlan@redhat.com>
Link: http://lkml.kernel.org/n/tip-p9ge2nvme7u5s21j0sn987wd@git.kernel.org
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
---
tools/perf/util/symbol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index e7bf0c46918d..b0d2fb272f7e 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -680,7 +680,7 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso, struct map *map,
pos->start -= curr_map->start - curr_map->pgoff;
if (pos->end)
pos->end -= curr_map->start - curr_map->pgoff;
- if (curr_map != map) {
+ if (curr_map->dso != map->dso) {
rb_erase_init(&pos->rb_node, root);
symbols__insert(
&curr_map->dso->symbols[curr_map->type],
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | tip-bot for Jiri Olsa <tipbot@zytor.com> |
|---|---|
| Date | 2015-10-29 10:50 +0100 |
| Subject | [tip:perf/core] perf symbols: Fix endless loop in dso__split_kallsyms_for_kcore |
| Message-ID | <qoS0i-6Ul-15@gated-at.bofh.it> |
| In reply to | #1255969 |
Commit-ID: 443f8c75e8d58d394b0e65b47e02e5cd8ed32b41
Gitweb: http://git.kernel.org/tip/443f8c75e8d58d394b0e65b47e02e5cd8ed32b41
Author: Jiri Olsa <jolsa@redhat.com>
AuthorDate: Mon, 26 Oct 2015 14:51:30 +0100
Committer: Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Wed, 28 Oct 2015 11:19:30 -0300
perf symbols: Fix endless loop in dso__split_kallsyms_for_kcore
Currently we split symbols based on the map comparison, but symbols are stored
within dso objects and maps could point into same dso objects (kernel maps).
Hence we could end up changing rbtree we are currently iterating and mess it
up. It's easily reproduced on s390x by running:
$ perf record -a -- sleep 3
$ perf buildid-list -i perf.data --with-hits
The fix is to compare dso objects instead.
Reported-by: Michael Petlan <mpetlan@redhat.com>
Signed-off-by: Jiri Olsa <jolsa@kernel.org>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: Andi Kleen <ak@linux.intel.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20151026135130.GA26003@krava.brq.redhat.com
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
tools/perf/util/symbol.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 71bf711..b4cc766 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -680,7 +680,7 @@ static int dso__split_kallsyms_for_kcore(struct dso *dso, struct map *map,
pos->start -= curr_map->start - curr_map->pgoff;
if (pos->end)
pos->end -= curr_map->start - curr_map->pgoff;
- if (curr_map != map) {
+ if (curr_map->dso != map->dso) {
rb_erase_init(&pos->rb_node, root);
symbols__insert(
&curr_map->dso->symbols[curr_map->type],
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web