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 ~]$
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/
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 ~]$
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.
(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 ...
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]$
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'
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
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
(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]$
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]$
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
file-5.03-14.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/file-5.03-14.fc12
(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
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.
file-5.04-4.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/file-5.04-4.fc13
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.