Bug 410631

Summary: add full executable path .note to corefile
Product: Red Hat Enterprise Linux 5 Reporter: Andrew Cagney <cagney>
Component: kernelAssignee: Red Hat Kernel Manager <kernel-mgr>
Status: CLOSED DUPLICATE QA Contact: Martin Jenner <mjenner>
Severity: low Docs Contact:
Priority: low    
Version: 5.1CC: ebachalo, jan.kratochvil, nhorman, pmuldoon
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-11-17 17:23:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 173278    

Description Andrew Cagney 2007-12-04 16:42:58 UTC
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 18:57:07 UTC
Adding another frysk bug, caused by the limitation.

Comment 2 Neil Horman 2008-08-05 15:17:35 UTC
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 14:10:01 UTC
(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 14:52:19 UTC
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 15:42:52 UTC
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 05:44:15 UTC
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 17:22:57 UTC
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 17:23:21 UTC

*** This bug has been marked as a duplicate of bug 410871 ***

Comment 10 Jan Kratochvil 2011-12-06 21:29:38 UTC
Besides implemented build-id it is now also implemented by ABRT and its corefile associated files:
/var/spool/abrt/ccpp-*/executable