This is the mail archive of the
mailing list for the elfutils project.
Re: How to associate Elf with Dwfl_Module returned by dwfl_report_module
- From: Ulf Hermann <ulf dot hermann at qt dot io>
- To: elfutils-devel at sourceware dot org
- Date: Thu, 22 Mar 2018 10:11:29 +0100
- Subject: Re: How to associate Elf with Dwfl_Module returned by dwfl_report_module
- References: <3517953.ztkfjMdy38@agathebauer> <20180320220549.GD6269@wildebeest.org> <1946852.ajpeOdNFGP@agathebauer>
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
> 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.