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
Suggest writing out the full original executable path to a separate .note section.
Adding another frysk bug, caused by the limitation.
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
(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.
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
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).
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.
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 ) 
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
*** This bug has been marked as a duplicate of bug 410871 ***
Besides implemented build-id it is now also implemented by ABRT and its corefile associated files: