From: Milian Wolff <milian.wolff@kdab.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Jiri Olsa <jolsa@kernel.org>, Namhyung Kim <namhyung@kernel.org>,
Linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org,
Jin Yao <yao.jin@linux.intel.com>
Subject: Re: [PATCH 3/3] perf report: don't crash on invalid inline debug information
Date: Tue, 16 Oct 2018 21:00:48 +0200 [thread overview]
Message-ID: <19251847.rgPmgX8CgI@agathebauer> (raw)
In-Reply-To: <20181016175204.GF3849@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 6018 bytes --]
On Dienstag, 16. Oktober 2018 19:52:04 CEST Arnaldo Carvalho de Melo wrote:
> Em Tue, Oct 16, 2018 at 02:49:23PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Oct 15, 2018 at 10:51:36PM +0200, Milian Wolff escreveu:
> > > On Donnerstag, 11. Oktober 2018 21:39:20 CEST Arnaldo Carvalho de Melo
wrote:
> > > > Em Thu, Oct 11, 2018 at 08:23:31PM +0200, Milian Wolff escreveu:
> > > > > On Donnerstag, 27. September 2018 21:10:37 CEST Arnaldo Carvalho de
> > > > > Melo
> > > > >
> > > > > wrote:
> > > > > > Em Wed, Sep 26, 2018 at 03:52:07PM +0200, Milian Wolff escreveu:
> > > > > > > When the function name for an inline frame is invalid, we must
> > > > > > > not try to demangle this symbol, otherwise we crash with:
> > > > > > >
> > > > > > > #0 0x0000555555895c01 in bfd_demangle ()
> > > > > > > #1 0x0000555555823262 in demangle_sym (dso=0x555555d92b90,
> > > > > > > elf_name=0x0,
> > > > > > > kmodule=0) at util/symbol-elf.c:215 #2 dso__demangle_sym
> > > > > > > (dso=dso@entry=0x555555d92b90, kmodule=<optimized out>,
> > > > > > > kmodule@entry=0,
> > > > > > > elf_name=elf_name@entry=0x0) at util/symbol-elf.c:400 #3
> > > > > > > 0x00005555557fef4b in new_inline_sym (funcname=0x0,
> > > > > > > base_sym=0x555555d92b90, dso=0x555555d92b90) at
> > > > > > > util/srcline.c:89 #4
> > > > > > > inline_list__append_dso_a2l (dso=dso@entry=0x555555c7bb00,
> > > > > > > node=node@entry=0x555555e31810, sym=sym@entry=0x555555d92b90) at
> > > > > > > util/srcline.c:264 #5 0x00005555557ff27f in addr2line
> > > > > > > (dso_name=dso_name@entry=0x555555d92430
> > > > > > > "/home/milian/.debug/.build-id/f7/186d14bb94f3c6161c010926da6603
> > > > > > > 3d24fc
> > > > > > > e5/
> > > > > > > elf", addr=addr@entry=2888, file=file@entry=0x0,>
> > > > > > >
> > > > > > > line=line@entry=0x0, dso=dso@entry=0x555555c7bb00,
> > > > > > > unwind_inlines=unwind_inlines@entry=true,
> > > > > > > node=0x555555e31810,
> > > > > > > sym=0x555555d92b90) at util/srcline.c:313>
> > > > > > >
> > > > > > > #6 0x00005555557ffe7c in addr2inlines (sym=0x555555d92b90,
> > > > > > > dso=0x555555c7bb00, addr=2888, dso_name=0x555555d92430
> > > > > > > "/home/milian/.debug/.build-id/f7/186d14bb94f3c6161c010926da6603
> > > > > > > 3d24fc
> > > > > > > e5/
> > > > > > > elf")>
> > > > > > >
> > > > > > > at util/srcline.c:358
> > > > > > >
> > > > > > > So instead handle the case where we get invalid function names
> > > > > > > for inlined frames and use a fallback '??' function name
> > > > > > > instead.
> > > > > > >
> > > > > > > While this crash was originally reported by Hadrien for rust
> > > > > > > code,
> > > > > > > I can now also reproduce it with trivial C++ code. Indeed, it
> > > > > > > seems
> > > > > > > like libbfd fails to interpret the debug information for the
> > > > > > > inline
> > > > > > > frame symbol name:
> > > > > > >
> > > > > > > $ addr2line -e
> > > > > > > /home/milian/.debug/.build-id/f7/186d14bb94f3c6161c010926da66033
> > > > > > > d24fce
> > > > > > > 5/e
> > > > > > > lf -if b48 main
> > > > > > > /usr/include/c++/8.2.1/complex:610
> > > > > > > ??
> > > > > > > /usr/include/c++/8.2.1/complex:618
> > > > > > > ??
> > > > > > > /usr/include/c++/8.2.1/complex:675
> > > > > > > ??
> > > > > > > /usr/include/c++/8.2.1/complex:685
> > > > > > > main
> > > > > > > /home/milian/projects/kdab/rnd/hotspot/tests/test-clients/cpp-in
> > > > > > > lining
> > > > > > > /mai
> > > > > > > n.cpp:39
> > > > > > >
> > > > > > > I've reported this bug upstream and also attached a patch there
> > > > > > > which should fix this issue:
> > > > > > > https://sourceware.org/bugzilla/show_bug.cgi?id=23715
> > > > > >
> > > > > > Millian, what about this one, which is the cset it is fixing?
> > > > >
> > > > > Hey Arnaldo,
> > > > >
> > > > > just noticed this email and that the corresponding patch hasn't
> > > > > landed in
> > > > > perf/core yet. The patch set which introduced this is a64489c56c307
> > > > > ("perf
> > > > > report: Find the inline stack for a given address"). Note that the
> > > > > code
> > > > > was
> > > > > introduced by this patch, but then subsequently touched and moved by
> > > > > follow up patches. So, is this the patch you want to see referenced?
> > > > > Otherwise, the latest patch which gets fixed is afaik: 7285cf3325b4a
> > > > > ("perf srcline: Show correct function name for srcline of
> > > > > callchains").
> > > > >
> > > > > Can you please pick either of these patches and amend the commit
> > > > > message
> > > > > of my patch and push it to perf/urgent and perf/core?
> > > >
> > > > I'll reread all this later or tomorrow and continue, going AFK now.
> > >
> > > Ping?
> >
> > Applied, seems simple enough, makes this code a bit more robust.
> >
> > With regards to the cset where the problem originally was introduced,
> > i.e. not checking if a2l->funcname was NULL before either passing it to
> > strdup() or all the way to bfd_demangle(), that would cause the crash in
> >
> > either place, I think this is the cset:
> > commit a64489c56c307bf0955f0489158c5ecf6aa10fe2
> > Author: Jin Yao <yao.jin@linux.intel.com>
> > Date: Sun Mar 26 04:34:26 2017 +0800
> >
> > perf report: Find the inline stack for a given address
> >>
> >> Agreed?
>
> But I'm not sure this will be worth for doing backports, as before
> applying this patch a series of other patches touching this code would
> have to be applied :-\
>
> I can leave it there, so that we know when the problem was introduced,
> i.e. I _guess_ that if this rust or C++ reproducers would be used with
> perf built with a64489c56c307bf0955f0489158c5ecf6aa10fe2 as head, we
> would see a crash as well.
Yes, probably. And backporting this patch should be easily doable for anyone
with a little C knowledge ;-)
Cheers
--
Milian Wolff | milian.wolff@kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt, C++ and OpenGL Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3826 bytes --]
next prev parent reply other threads:[~2018-10-16 19:01 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-26 13:52 [PATCH 1/3] perf report: don't try to map ip to invalid map Milian Wolff
2018-09-26 13:52 ` [PATCH 2/3] perf report: use the offset address to find inline frames Milian Wolff
2018-09-27 16:00 ` Jiri Olsa
2018-09-27 19:12 ` Arnaldo Carvalho de Melo
2018-10-02 7:39 ` [PATCH] perf record: use unmapped IP for inline callchain cursors Milian Wolff
2018-10-02 15:32 ` Arnaldo Carvalho de Melo
2018-10-03 3:35 ` Ravi Bangoria
2018-10-05 13:48 ` Arnaldo Carvalho de Melo
2018-10-08 18:49 ` Milian Wolff
2018-10-05 14:11 ` Arnaldo Carvalho de Melo
2018-10-05 16:21 ` [tip:perf/urgent] perf record: Use " tip-bot for Milian Wolff
2018-09-26 13:52 ` [PATCH 3/3] perf report: don't crash on invalid inline debug information Milian Wolff
2018-09-27 19:10 ` Arnaldo Carvalho de Melo
2018-10-11 18:23 ` Milian Wolff
2018-10-11 19:39 ` Arnaldo Carvalho de Melo
2018-10-15 20:51 ` Milian Wolff
2018-10-16 17:49 ` Arnaldo Carvalho de Melo
2018-10-16 17:52 ` Arnaldo Carvalho de Melo
2018-10-16 19:00 ` Milian Wolff [this message]
2018-10-16 20:06 ` Arnaldo Carvalho de Melo
2018-10-18 6:20 ` [tip:perf/urgent] perf report: Don't " tip-bot for Milian Wolff
2018-09-26 14:18 ` [PATCH 1/3] perf report: don't try to map ip to invalid map Arnaldo Carvalho de Melo
2018-09-26 14:41 ` Milian Wolff
2018-09-27 19:07 ` Arnaldo Carvalho de Melo
2018-09-27 8:48 ` Sandipan Das
2018-09-27 19:11 ` Arnaldo Carvalho de Melo
2018-09-27 16:02 ` Jiri Olsa
2018-10-05 16:20 ` [tip:perf/urgent] perf report: Don't " tip-bot for 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=19251847.rgPmgX8CgI@agathebauer \
--to=milian.wolff@kdab.com \
--cc=Linux-kernel@vger.kernel.org \
--cc=acme@kernel.org \
--cc=jolsa@kernel.org \
--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).