public inbox for elfutils@sourceware.org
 help / color / mirror / Atom feed
From: Ulf Hermann <ulf.hermann@qt.io>
To: elfutils-devel@sourceware.org
Subject: Re: How to associate Elf with Dwfl_Module returned by dwfl_report_module
Date: Thu, 22 Mar 2018 09:11:00 -0000	[thread overview]
Message-ID: <5bed10d0-beb2-be95-b22c-3cadba3ad506@qt.io> (raw)
In-Reply-To: <1946852.ajpeOdNFGP@agathebauer>

Hi Milian,

> I am regularly seeing broken backtraces for samples where I have 
> the gut feeling that missing reported ELFs are to blame. But we report 
> everything, except for scenarios where the mmap events seemingly overlap.

Actually, at least for perfparser that's not quite true. When perfparser encounters an overlap error, it will throw out the entire set of mappings and restart reporting, with the addresses from the current sample (see PerfSymbolTable::reportElf() and PerfSymbolTable::clearCache()). If that still gives you overlapping ranges, it means perf has not sent all the mmap events and therefore we're reporting the wrong ELF for some address in your sample. That wrong ELF may be larger than the one we actually want and therefore it can overlap some other ELF an address in your sample points to.

I've seen that happen. Make sure to keep your sample rate low enough to prevent perf from dropping anything.

I realize we could optimize the reporting a bit, with the dwfl_report_end callback Mark mentioned, but if you have addresses into two overlapping ELFs in one sample, that's fundamentally impossible to unwind.

Ulf

  parent reply	other threads:[~2018-03-22  9:11 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-17 13:15 Milian Wolff
2018-03-20 22:05 ` Mark Wielaard
2018-03-21 13:01   ` Milian Wolff
2018-03-21 14:23     ` Milian Wolff
2018-03-21 14:35       ` Ulf Hermann
2018-03-21 21:31       ` Mark Wielaard
2018-03-22 12:30         ` Milian Wolff
2018-03-21 21:21     ` Mark Wielaard
2018-03-22 12:29       ` Milian Wolff
2018-03-22  9:11     ` Ulf Hermann [this message]
2018-03-22 12:33       ` 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=5bed10d0-beb2-be95-b22c-3cadba3ad506@qt.io \
    --to=ulf.hermann@qt.io \
    --cc=elfutils-devel@sourceware.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).