Bug 486328

Created attachment 332548 [details]
Compressed testing core file

Created attachment 332549 [details]
Proposed patch

Reverse the order of probed PRPSINFO offsets.  Similar change is already present in the newer upstream versions.

thanks for the patch, it really did the trick

Comment on attachment 332549 [details]
Proposed patch

The patch is incorrect -- the strings areas may overlap and a longer command is then detected incorrectly.

The patch in comment #2 was taken from the upstream sources but even the new file-5.00 would fail in the following case:

1. bash -c "sleep 1d;echo 11111111111111111111111111111111111111112345678901234567890" &
2. kill -6 <pid of the previous command>
3. file <produced coredump>

Result:
core.12332: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from '11111123456789012345678'

Created attachment 332913 [details]
New patch

This patch was suggested by Masahiro Matsuya.  It does not bring in the regression.  It just assumes that the command string can't start with a space which is enough to fix the observed problem (the string detected at FreeBSD offset was always " N").

Created attachment 333042 [details]
More complex patch

I was wrong -- there could appear another printable character not just a space at the FreeBSD offset.  Therefore the previous patch is also wrong.

Here's another attempt:

I have modified the upstream patch: let's check the offsets from the large one but don't print out the first string found.  Probe also one character before the matched offset and the first character at the lower offset and if they both conform to the criteria continue guessing.  This way we should find the highest matching offset avoiding false positives caused by long command lines.

I have made some core dumps in freebsd

http://people.fedoraproject.org/~dnovotny/bsdcores.zip

and it seems they are detected as "os_style == OS_STYLE_FREEBSD",
so they are this way distinguishable from Linux core dumps and
can (or rather have to) be treated separately in the case
when you print the coredump commandline

This request was evaluated by Red Hat Product Management for
inclusion, but this component is not scheduled to be updated in
the current Red Hat Enterprise Linux release. If you would like
this request to be reviewed for the next minor release, ask your
support representative to set the next rhel-x.y flag to "?".

Created attachment 337754 [details]
the latest, cleanest version of the patch

we found BSD core files can go in another case, can be left off the cycle and not confuse the analysis of linux core files

fixed in file-4.17-16

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Cause: 64-bit Linux core file has printable characters in the PRPSINFO NOTE section at the offset where FreeBSD stores the
command name. File than thought it's the valid offset to get the command name from.

Consequence: This caused File to print bad command name ("from ' N'") for particular core files.

Fix: The offset where FreeBSD stores the command name is checked only when the core file was generated on FreeBSD platfrom.

Result: File does not try to get command name from FreeBSD offset if the core file is not created on FreeBSD and detects core file command name on 64bit Linux properly.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2012-0201.html