Bug 410631 - add full executable path .note to corefile
add full executable path .note to corefile
Status: CLOSED DUPLICATE of bug 410871
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: kernel (Show other bugs)
5.1
All Linux
low Severity low
: ---
: ---
Assigned To: Red Hat Kernel Manager
Martin Jenner
:
Depends On:
Blocks: 173278
  Show dependency treegraph
 
Reported: 2007-12-04 11:42 EST by Andrew Cagney
Modified: 2011-12-06 16:29 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-11-17 12:23:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Sourceware 6602 None None None Never

  None (edit)
Description Andrew Cagney 2007-12-04 11:42:58 EST
The executable path contained in the corefile is truncated to ~80 characters. 
This makes identifying a correct core file's executable (and re-starting the
executable) impossible.

Suggest writing out the full original executable path to a separate .note section.
Comment 1 Andrew Cagney 2008-06-11 14:57:07 EDT
Adding another frysk bug, caused by the limitation.
Comment 2 Neil Horman 2008-08-05 11:17:35 EDT
You shouldn't need this in RHEL5 after 5.2.  WE've backported  the core_pattern features from upstream, which allow you to pipe a core to an executable.  Using this feature you can extract the pid of the crashing process, and find the full pathname by doing a readlink on /proc/<pid>/exe
Comment 3 Andrew Cagney 2008-08-11 10:10:01 EDT
(In reply to comment #2)
> You shouldn't need this in RHEL5 after 5.2.  WE've backported  the core_pattern
> features from upstream, which allow you to pipe a core to an executable.  Using
> this feature you can extract the pid of the crashing process, and find the full
> pathname by doing a readlink on /proc/<pid>/exe

Is there a reference for the core_pattern feature?

Our problem is determining the original executable's name so that, for instance, we can "pipe" to it.  The 80 character limit causes this path to be truncated, and hence the exact executable to be unknown.
Comment 4 Neil Horman 2008-08-11 10:52:19 EDT
There is s reference, if you get the upstream git tree, and look in Documentation/sysctl/kernel.txt, the details of core_pattern are listed there
Comment 5 Jan Kratochvil 2008-08-14 11:42:52 EDT
BTW it is unfortunate if RH is going to depend on core_pattern.  I cannot find his citation but IIRC Roland McGrath was proposing the whole build-id F8+ feature than some userland program hook at the core dumping time to be able to dump cores even with very broken system (low on memory, userland execution broken etc.).  With the dependency on a userland core files dumper the build-id feature could be simplified a lot (IMO in fact it would not be needed at all).
Comment 6 Jan Kratochvil 2008-08-15 01:44:15 EDT
Please disregard my previous Comment 5.

Roland has nothing against core_pattern, the reasons against `rpm -qf' at the core_pattern dumping time are:
On Thu, 14 Aug 2008 22:41:08 +0200, Roland McGrath wrote:
> This is more complicated, has more dependencies and is more error-prone.
> You'd want it to record the exact package version, not just a name.  Then
> you'd want to verify that it really was the official unmodified version of
> that file.  So you're checking the file's md5sum--and worse, the full rpm -V
> work including prelink -y--but that is so slow, you'd surely save some
> cache indexed by dev+inode+ctime.  That is no small amount of hair, just to
> get back to the level of reliability of a plain simple core dump with ELF
> headers (assuming distro-level sanity ensures build IDs are properly unique).
>
> No fancy new plans obviate build ID at all.  It complements them,
> and gives a great leg up for implementing many such things.
Comment 8 Linda Wang 2008-11-17 12:22:57 EST
The feature core_pattern in RHEL5.3 will address this issue:

Tue Sep 09 2008 Don Zickus  [2.6.18-110.el5]
[misc] pipe support to /proc/sys/net/core_pattern (Neil Horman ) [410871]

per developer:
WE've backported  the core_pattern features from upstream, which allow you to pipe a core to an executable.  Using this feature you can extract the pid of the crashing process, and find the full pathname by doing a readlink on /proc/<pid>/exe
Comment 9 Linda Wang 2008-11-17 12:23:21 EST

*** This bug has been marked as a duplicate of bug 410871 ***
Comment 10 Jan Kratochvil 2011-12-06 16:29:38 EST
Besides implemented build-id it is now also implemented by ABRT and its corefile associated files:
/var/spool/abrt/ccpp-*/executable

Note You need to log in before you can comment on or make changes to this bug.