From: Anton Blanchard <anton@samba.org>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>,
Frederic Weisbecker <fweisbec@gmail.com>,
Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: perf annotate SEGVs
Date: Fri, 12 Feb 2010 19:17:24 +1100 [thread overview]
Message-ID: <20100212081724.GA13355@kryten> (raw)
In-Reply-To: <20100212052427.GK3399@kryten>
Hi,
I think I understand a problem in perf annotate where I see random corruption
(rb tree issues, glibc malloc failures etc).
The issue happens with zero length symbols, in this particular case they
are kernel functions written entirely in assembly, eg .copy_4K_page,
.__copy_tofrom_user and .memcpy:
Num: Value Size Type Bind Vis Ndx Name
63516: c00000000004a774 212 FUNC GLOBAL DEFAULT 1 .devm_ioremap_prot
69095: c00000000004a848 0 FUNC GLOBAL DEFAULT 1 .copy_4K_page
62002: c00000000004aa00 0 FUNC GLOBAL DEFAULT 1 .__copy_tofrom_user
50576: c00000000004b000 0 FUNC GLOBAL DEFAULT 1 .memcpy
69557: c00000000004b278 176 FUNC GLOBAL DEFAULT 1 .copy_in_user
51841: c00000000004b328 144 FUNC GLOBAL DEFAULT 1 .copy_to_user
In symbol_filter we look at the length of each symbol:
static int symbol_filter(struct map *map __used, struct symb
...
const int size = (sizeof(*priv->hist) +
(sym->end - sym->start) * sizeof(u64));
And since start == end we create 0 bytes of space for the ip[] array.
Later on in hist_hit we then start indexing off this array:
h->ip[offset]++;
Which then corrupts whatever is next in memory. With large assembly functions
we corrupt a lot :)
How should we fix this? Do we need to do a first pass through our symbols
to fixup ->end before allocating the ->ip[] arrays?
Anton
next parent reply other threads:[~2010-02-12 8:19 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100212052427.GK3399@kryten>
2010-02-12 8:17 ` Anton Blanchard [this message]
2010-02-12 11:59 ` perf annotate SEGVs Arnaldo Carvalho de Melo
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=20100212081724.GA13355@kryten \
--to=anton@samba.org \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
/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