This is the mail archive of the mailing list for the elfutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [patch 0/3] Live PIDs with deleted files by /dev/PID/mem

On Tue, 25 Feb 2014 23:03:43 +0100, Mark Wielaard wrote:
> On Sat, 2014-02-22 at 22:08 +0100, Jan Kratochvil wrote:
> > jankratochvil/devmem
> The name, the subject and some of the comments talks about /dev.
> But I assume this is really about /proc?

Right, there isn't anything related to "dev", my mistake.

> > (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.
I was more hoping here that in reality prelink is/will not be in use much.
Also it is not a regression - processes with deleted files could not be
backtraced at all so far.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]