linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Petlan <mpetlan@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: linux-perf-users@vger.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Jiri Olsa <jolsa@kernel.org>, Ingo Molnar <mingo@kernel.org>,
	David Ahern <dsahern@gmail.com>, Wang Nan <wangnan0@huawei.com>
Subject: Re: bogus values of variables in userspace probes
Date: Tue, 24 Nov 2015 19:30:39 +0100	[thread overview]
Message-ID: <1448389839.24573.21.camel@redhat.com> (raw)
In-Reply-To: <20151124150819.GD18140@kernel.org>

On Tue, 2015-11-24 at 12:08 -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Nov 24, 2015 at 12:18:22PM +0100, Michael Petlan escreveu:
> > I have been playing with perf-probe tool and I found out that some bogus
> > values of a function argument are obtained by perf-record.
> > 
> > How to reproduce:
> > 
> > gcc -O0 -g -o dummy dummy.c
> > perf probe -x ./dummy --add 'isprime a'
> > perf record -e probe_dummy:isprime ./dummy
> > perf script
> > 
> > The actual output looks like the following:
> > 
> > dummy 32476 [000] 3534401.838454: probe_dummy:isprime: (400530) a=32767
> > dummy 32476 [000] 3534401.838504: probe_dummy:isprime: (400530) a=32714
> > dummy 32476 [000] 3534401.838513: probe_dummy:isprime: (400530) a=3
> > dummy 32476 [000] 3534401.838519: probe_dummy:isprime: (400530) a=4
> > dummy 32476 [000] 3534401.838525: probe_dummy:isprime: (400530) a=5
> > dummy 32476 [000] 3534401.838531: probe_dummy:isprime: (400530) a=6
> > dummy 32476 [000] 3534401.838537: probe_dummy:isprime: (400530) a=7
> > dummy 32476 [000] 3534401.838543: probe_dummy:isprime: (400530) a=13
> > dummy 32476 [000] 3534401.838561: probe_dummy:isprime: (400530) a=17
> > 
> > But if you look into the source, you can see that the function isprime()
> > is called with the following arguments:
> > 
> > int numbers[] = { 2, 3, 4, 5, 6, 7, 13, 17, 19 };
> > 
> > So the first and last ones are omitted, there are some bogus numbers instead
> > of them and all that is shifted somehow.
> > 
> > Note that when I probe for %ax register it looks correct.
> > 
> > The version of kernel/perf is 4.3.0. The architecture is x86_64.
> > Am I missing something or is it a bug?
> 
> I'm now trying to bisect that register error I found while trying to
> reproduce the problem reported above, but please consider writing a
> 'perf test' entry that does exactly what you did, i.e. have a simple
> program that you build with a known set of compile flags, then run it
> using perf probe to catch a specific function, its argument, and then
> check that the values it produces are the ones expected.
> 
> We would catch bugs in 'perf probe', the DWARF code, etc, much more
> quickly with something like that in place. :-)

Hi Arnaldo,

thanks for investigating the issue. I do not use fedora kernel, I use
what I build from git, but of course I am some versions back. So I use
4.3.0 and 4.3.0-rc5 and both do the same thing.

I have met this when writing new tests for perf-probe into the testsuite
I had been speaking about some time ago [1]. But if needed, I may add it
as a perf-test entry as you wish.

Michael

> 
> - Arnaldo

  reply	other threads:[~2015-11-24 18:30 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-11-24 11:18 bogus values of variables in userspace probes Michael Petlan
2015-11-24 14:54 ` Arnaldo Carvalho de Melo
2015-11-24 16:13   ` Arnaldo Carvalho de Melo
2015-11-25  6:32     ` 平松雅巳 / HIRAMATU,MASAMI
2015-11-25 10:34   ` [BUGFIX PATCH perf/core ] perf probe: Fix to free temporal Dwarf_Frame correctly Masami Hiramatsu
2015-11-24 15:08 ` bogus values of variables in userspace probes Arnaldo Carvalho de Melo
2015-11-24 18:30   ` Michael Petlan [this message]
2015-11-24 19:16     ` Arnaldo Carvalho de Melo
2015-11-25 13:25       ` Michael Petlan
2015-11-25 13:33         ` Jiri Olsa
2015-11-25 14:43           ` perftool-testsuite was: " Arnaldo Carvalho de Melo
2015-11-25 15:58             ` Michael Petlan
2015-11-25 19:27               ` Arnaldo Carvalho de Melo
2015-11-25 15:07         ` 平松雅巳 / HIRAMATU,MASAMI
2015-11-25  1:03     ` 平松雅巳 / HIRAMATU,MASAMI
2015-11-25  2:24       ` 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=1448389839.24573.21.camel@redhat.com \
    --to=mpetlan@redhat.com \
    --cc=acme@kernel.org \
    --cc=dsahern@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@kernel.org \
    --cc=wangnan0@huawei.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).