On Sun, 2014-03-02 at 22:54 +0100, Jan Kratochvil wrote:
On Tue, 25 Feb 2014 23:03:43 +0100, Mark Wielaard wrote:
> On Sat, 2014-02-22 at 22:08 +0100, Jan Kratochvil wrote:
> > (3)
> > There is currently a bug in symbol resolving (eu-stack without -q) of deleted
> > prelinked executables.
> >
> > This is because this libdwfl/dwfl_module_getdwarf.c comment is no longer true
> > after this patch
> > If there are no section headers at all (full stripping), then
> > the end of the first segment is a valid synchronization address.
> > This cannot happen in a prelinked file, since prelink itself
> > relies on section headers for prelinking and for undoing it.
> > (If you do full stripping on a prelinked file, then you get what
> > you deserve--you can neither undo the prelinking, nor expect to
> > line it up with a debug file separated before prelinking.)
> >
> > because /proc/PID/mem does not have to have section headers mapped.
> >
> > Primarily I am not aware how to fix it.
>
> I also don't immediately know how. But nice find. This seems somewhat
> obscure. It means, the main ELF file is deleted, but you do still have
> the separate debuginfo file around, which we find (based on build-id)
> and then cannot properly match/sync because the main, now deleted, file
> was prelinked. I think in general the main file and the separate
> debuginfo file will both be deleted. It is a slightly confusing corner
> case though.
On a system with prelink it can commonly happen:
Install daemon.rpm and daemon-debuginfo.rpm.
During some night cron.daily runs prelink, /usr/bin/daemon gets prelinked.
Start daemon - it will be started prelinked.
Some night cron.daily runs prelink again and, it may re-prelink whole system
as PRELINK_FULL_TIME_INTERVAL=14 just happened.
daemon in memory is "daemon (deleted)" running prelinked executable.
State of /usr/bin/daemon does not matter now anymore.
/usr/lib/debug/usr/bin/daemon.debug still exists (it is always unprelinked).
Run eu-stack -p `pidof daemon`.
In this case it will fail:
In-memory deleted executable is not expected to be prelinked by the paragraph
above while in reality it is prelinked. Therefore elfutils wrongly matches
it to /usr/lib/debug/usr/bin/daemon.debug which is not prelinked.
This is a pretty normal case on a system using prelink.
Urgh, you are completely right. I hadn't thought about that. But yes,
re-prelinking would indeed trigger this exact situation.
Thanks,
Mark