Bug 566305

Summary: "file" may trim too much of command line from core file
Product: [Fedora] Fedora Reporter: Steve Tyler <stephent98>
Component: fileAssignee: Daniel Novotny <dnovotny>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 12CC: dnovotny
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: file-5.03-14.fc12 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 580490 (view as bug list) Environment:
Last Closed: 2010-04-07 14:16:52 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: 580490, 826897    
Attachments:
Description Flags
a patch none

Description Steve Tyler 2010-02-17 20:55:08 UTC 
Description of problem:
I commonly use "file" to quickly identify the origin of core files. Sometimes the command line is trimmed to the point of silliness. For example:

$ file core.2493
core.2493: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'gee --rid=48373'

$ which gee
/usr/bin/which: no gee in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/stephent/bin)

$ strings core.2493 | head | grep gee
/usr/bin/python /usr/lib/python2.6/site-packages/rpdb2.py --debugee --rid=48373

Version-Release number of selected component (if applicable):
file-5.03-12.fc12.x86_64

How reproducible:
Always on the same core file.
Varies among core files.

Steps to Reproduce:
1. Enable core file generation. (I put "ulimit -c unlimited" in my .bashrc.)
2. Start a long-running program. (I haven't found a specific example, yet.)
3. Generate a core file by terminating the prog. with "Ctrl-\" or "kill -3 <pid>".
4. Run "file" on the resulting core file.
  
Actual results:
"file" may trim the command line so much that the program cannot be identified.

Expected results:
"file" reports enough of the command line that the program that generated the core file can be identified. For example:

$ basename '/usr/bin/python /usr/lib/python2.6/site-packages/rpdb2.py --debugee --rid=48373'
rpdb2.py --debugee --rid=48373

Additional info:

Identifying the command that generated a core file is also essential to examining the core file with gdb.

This works as expected:

[stephent@walnut ~]$ /bin/sleep 60000000000000000000000000000000000000000
^\Quit (core dumped)
[stephent@walnut ~]$ ls -lt core* | head -1
-rw------- 1 stephent stephent    356352 2010-02-17 12:32 core.4938
[stephent@walnut ~]$ file core.4938
core.4938: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/bin/sleep 60000000000000000000000000000000000000000'
[stephent@walnut ~]$
Comment 1 Steve Tyler 2010-03-25 19:43:26 UTC 
Here is a way using firefox to generate a core file that reproduces this bug.

Procedure:
1. Exit all instances of firefox.
2. From a terminal run:
   $ /usr/lib64/firefox-3.5.8/firefox http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.TC1/Fedora/i386/iso/
3. From another terminal run:
   $ ps -ef | grep firefox # to get pid, say 5958
   $ kill -3 5958
4. $ file core.5958

Actual results:
[stephent@walnut ~]$ file core.5958
core.5958: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'ct.org/pub/alt/'

[stephent@walnut ~]$ strings core.5958 | grep 'ct.org/pub/alt/' | head -1
/usr/lib64/firefox-3.5.8/firefox http://serverbeach1.fedoraproject.org/pub/alt/
Comment 2 Steve Tyler 2010-03-25 20:01:25 UTC 
It appears that in the two cases of over-trimming, "file" is returning the last 15 characters of the command line from the core file.

[stephent@walnut ~]$ echo -n 'ct.org/pub/alt/' | wc -c
15
[stephent@walnut ~]$ echo -n 'gee --rid=48373' | wc -c
15
[stephent@walnut ~]$
Comment 3 Daniel Novotny 2010-03-26 11:55:40 UTC 
Steve, thanks for the reproducer. Generated a firefox core file, which exposes the bug. I was about to attach the file to the bugzilla, but it is 127M large... I will analyze the problem.
Comment 4 Steve Tyler 2010-03-26 14:33:05 UTC 
(In reply to comment #3)
> Steve, thanks for the reproducer. Generated a firefox core file, which exposes
> the bug. I was about to attach the file to the bugzilla, but it is 127M
> large... I will analyze the problem.    

Thanks for looking into this.

FWIW, xz compressed a core file from 190M to 8.0M,
which is below BZ's 20000 KB size limit:

$ xz -9e core.4553

However, a firefox core file could expose passwords and browser history ...
Comment 5 Steve Tyler 2010-03-26 15:11:24 UTC 
Here's another reproducer:

Create a deeply nested directory, e.g. foo/foo/foo.

[stephent@walnut foo]$ pwd
/home/stephent/src/exp/python1/foo/foo/foo

Put the follwing python script in it:

[stephent@walnut foo]$ cat sleep1.py 
#!/usr/bin/python
import time
time.sleep(1000)

Run sleep1.py with the full path and terminate with 'ctrl-\'.

[stephent@walnut foo]$ /usr/bin/python `pwd`/sleep1.py
^\Quit (core dumped)
[stephent@walnut foo]$ ./sleep1.py
^\Quit (core dumped)

[stephent@walnut foo]$ file core.*
core.7990: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '1.py'
core.7992: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/python ./sleep1.py'
[stephent@walnut foo]$
Comment 6 Steve Tyler 2010-03-26 15:38:26 UTC 
By removing one character at a time from the path, it is possible to get a path in which "file" reports a null string for the command line. If one more character is removed from the path, "file" reports the full command line. The last two core files below illustrate this behavior.

[stephent@walnut f]$ pwd
/home/stephent/src/exp/python1/fo/f/f
[stephent@walnut f]$ file core.*
core.7990: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '1.py'
core.7992: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/python ./sleep1.py'
core.8281: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '.py'
core.8292: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'py'
core.8306: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'y'
core.8318: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from ''
core.8349: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/usr/bin/python /home/stephent/src/exp/python1/fo/f/f/sleep1.py'
Comment 7 Steve Tyler 2010-03-26 16:23:33 UTC 
Super-simple reproducer:

[stephent@walnut file-command]$ sleep 1234567890123456789012345678901234567890123456789012345678
^\Quit (core dumped)
[stephent@walnut file-command]$ file core*
core.9429: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from ''
[stephent@walnut file-command]$ 

The command is exactly 64 characters long:

[stephent@walnut file-command]$ echo -n 'sleep 1234567890123456789012345678901234567890123456789012345678' | wc -c
64
Comment 8 Daniel Novotny 2010-03-31 13:21:34 UTC 
Created attachment 403740 [details]
a patch

We had a similar problem in RHEL, where file was incorrectly clasifying the core as being from FreeBSD. The patch for that does not completely solve the problem, but now the output is a bit better. I have made a scratch build, so you can test if this partially help you before the problem is solved.

http://koji.fedoraproject.org/koji/taskinfo?taskID=2086984
Comment 9 Steve Tyler 2010-03-31 18:21:41 UTC 
(In reply to comment #8)
> Created an attachment (id=403740) [details]
> a patch
> 
> We had a similar problem in RHEL, where file was incorrectly clasifying the
> core as being from FreeBSD. The patch for that does not completely solve the
> problem, but now the output is a bit better. I have made a scratch build, so
> you can test if this partially help you before the problem is solved.
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=2086984    

Thanks, Daniel. The sleep command case results in a null string for the command line.

[stephent@walnut file-command]$ sleep 1234567890123456789012345678901234567890123456789012345678
^\Quit (core dumped)
[stephent@walnut file-command]$ ls
core.8793
[stephent@walnut file-command]$ file core.8793 
core.8793: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from ''
[stephent@walnut file-command]$ 
[stephent@walnut file-command]$ which file
/usr/bin/file
[stephent@walnut file-command]$ rpm -qf /usr/bin/file
file-5.03-14.566305.fc12.x86_64
[stephent@walnut file-command]$
Comment 10 Steve Tyler 2010-03-31 18:28:41 UTC 
No difference for the firefox case either.

[stephent@walnut file-command]$ /usr/lib64/firefox-3.5.8/firefox http://serverbeach1.fedoraproject.org/pub/alt/stage/13-Beta.TC1/Fedora/i386/iso/
^\Quit (core dumped)
[stephent@walnut file-command]$ ls
core.8793  core.8878
[stephent@walnut file-command]$ file core.8878
core.8878: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'ct.org/pub/alt/'

This is what I have installed.

[stephent@walnut file-command]$ rpm -qlv file
-rwxr-xr-x    1 root    root                    16016 Mar 31 06:19 /usr/bin/file
drwxr-xr-x    2 root    root                        0 Mar 31 06:19 /usr/share/doc/file-5.03
-rw-r--r--    1 root    root                     1650 Feb  5  2008 /usr/share/doc/file-5.03/COPYING
-rw-r--r--    1 root    root                    24336 May  6  2009 /usr/share/doc/file-5.03/ChangeLog
-rw-r--r--    1 root    root                     5674 Feb 14  2009 /usr/share/doc/file-5.03/README
-rw-r--r--    1 root    root                     6690 Mar 31 06:19 /usr/share/man/man1/file.1.gz
[stephent@walnut file-command]$ rpm -qlv file-libs
lrwxrwxrwx    1 root    root                       17 Mar 31 06:19 /usr/lib64/libmagic.so.1 -> libmagic.so.1.0.0
-rwxr-xr-x    1 root    root                   111656 Mar 31 06:19 /usr/lib64/libmagic.so.1.0.0
drwxr-xr-x    2 root    root                        0 Mar 31 06:19 /usr/share/file
lrwxrwxrwx    1 root    root                        8 Mar 31 06:19 /usr/share/file/magic -> ../magic
lrwxrwxrwx    1 root    root                       10 Mar 31 06:19 /usr/share/magic -> misc/magic
-rw-r--r--    1 root    root                     5575 Mar 31 06:19 /usr/share/man/man5/magic.5.gz
-rw-r--r--    1 root    root                   536982 Mar 31 06:19 /usr/share/misc/magic
-rw-r--r--    1 root    root                  1755800 Mar 31 06:19 /usr/share/misc/magic.mgc
[stephent@walnut file-command]$ 

[stephent@walnut file-command]$ rpm -Va file file-libs
[stephent@walnut file-command]$
Comment 11 Daniel Novotny 2010-04-07 14:16:52 UTC 
seems Debian patch from

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=422524

does the trick.

fixed in rawhide: file-5.04-7.fc14

I will make builds for F12, too
Comment 12 Fedora Update System 2010-04-07 14:31:35 UTC 
file-5.03-14.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/file-5.03-14.fc12
Comment 13 Steve Tyler 2010-04-07 18:02:26 UTC 
(In reply to comment #12)
> file-5.03-14.fc12 has been submitted as an update for Fedora 12.
> http://admin.fedoraproject.org/updates/file-5.03-14.fc12    

Thanks, Daniel. Confirming that both test cases work as expected with F12.

[stephent@walnut file-command]$ file core*
core.8793: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from 'sleep 1234567890123456789012345678901234567890123456789012345678'
core.8878: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/usr/lib64/firefox-3.5.8/firefox http://serverbeach1.fedoraproject.org/pub/alt/'
[stephent@walnut file-command]$ rpm -q file
file-5.03-14.fc12.x86_64
Comment 14 Fedora Update System 2010-04-16 23:40:32 UTC 
file-5.03-14.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 15 Fedora Update System 2010-05-27 13:29:57 UTC 
file-5.04-4.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/file-5.04-4.fc13
Comment 16 Fedora Update System 2010-06-10 19:24:05 UTC 
file-5.04-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.