Description of problem: The file command can report a wrong command name on certain ELF core files. Version-Release number of selected component (if applicable): file-4.17-15 How reproducible: always Steps to Reproduce: 1. run file command on the attached core file Actual results: core.19858: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from ' N' Expected results: core.19858: ELF 64-bit LSB core file AMD x86-64, version 1 (SYSV), SVR4-style, from 'sleep' Additional info: The core file was generated on an x86-64 system (reported also on IA-64) this way: 1. useradd -u 20000 hoge 2. su - hoge 3. ulimit -c unlimited 4. sleep 1d & 5. kill -6 <pid of the sleep command> The problem is caused by the fact that the 64-bit Linux core file has printable characters in the PRPSINFO NOTE section at the offset where FreeBSD stores the command name. Probing the offsets in reversed order fixes the issue.
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