Bug 195750

Summary: procps binaries segfault on x86_64
Product: [Fedora] Fedora Reporter: Doug Rosser <drosser>
Component: procpsAssignee: Daniel Novotny <dnovotny>
Status: CLOSED CANTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: mschlens, tsmetana
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-05-14 13:50:37 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:

Description Doug Rosser 2006-06-17 01:30:20 UTC
Description of problem:
All binaries in the procps package seem to segfault.

Version-Release number of selected component (if applicable):
$ rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" | grep procps
procps-3.2.6-3.4.x86_64
procps-debuginfo-3.2.6-3.4.x86_64

How reproducible:
Every time

Steps to Reproduce:
$ ps -ef
Segmentation fault
  
Actual results:
see above

Expected results:
see above

Additional info:
$ gdb /bin/ps
GNU gdb Red Hat Linux (6.3.0.0-1.122rh)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu"...Using host libthread_db
library "/lib64/libthread_db.so.1".

(gdb) break main
Breakpoint 1 at 0x401f40: file ps/display.c, line 547.
(gdb) run
Starting program: /bin/ps

Program received signal SIGSEGV, Segmentation fault.
0x00002aaaaaada77d in set_fast_math () at ../../gcc/config/i386/crtfastmath.c:108
108     ../../gcc/config/i386/crtfastmath.c: No such file or directory.
        in ../../gcc/config/i386/crtfastmath.c

also...
$ cat /proc/cpuinfo
processor       : 0
vendor_id       : AuthenticAMD
cpu family      : 15
model           : 0
model name      : AMD ClawHammer(tm)
stepping        : 0
cpu MHz         : 800.000
cache size      : 256 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 1
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow
bogomips        : 1599.30
TLB size        : 1024 4K pages
clflush size    : 64
cache_alignment : 64
address sizes   : 40 bits physical, 48 bits virtual
power management: fid vid

$ uname -a
Linux /*hostname removed*/ 2.6.16-1.2133_FC5 #1 SMP Tue Jun 6 00:51:53 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux

Comment 1 Karel Zak 2006-06-26 10:50:10 UTC
It works for me. There must be wrong anything other in your system, because your
report is alone, although x86_64 is used very often...

$ rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" | grep procps
procps-3.2.6-3.4.x86_64

$ ps -ef | wc -l
110

$ uname -a
Linux hostname.domain 2.6.16-1.2133_FC5 #1 SMP Tue Jun 6 00:51:53 EDT 2006
x86_64 x86_64 x86_64 GNU/Linux



Comment 3 Albert Cahalan 2006-12-25 20:20:56 UTC
For troubleshooting, he might try installing the upstream version.
It's very easy to do:

wget http://procps.sf.net/procps-3.2.7.tar.gz
tar zxf procps-3.2.7.tar.gz
cd procps-3.2.7.tar.gz
make install


Comment 4 Tomas Smetana 2007-05-14 13:50:37 UTC
I can't reproduce the problem and nobody else reports this. Since the submitter
did not provide any further information I'm closing the bug.

Comment 5 Marc Schlensog 2009-07-09 10:27:50 UTC
Sorry for re-opening this ancient bug but it still seems to be present in F11.
It seems to be a bug related to the hardware, as I seem to have the same system (AMD Solo). I don't know if anyone is still interested in fixing bugs that only show up on 7yr old pre-production hardware. But if so, I'll try to be helpful in any way possible.

Here some more information:

$ rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" | grep procps
procps-3.2.7-27.fc11.x86_64

$ uname -a
Linux localhost 2.6.29.5-191.fc11.x86_64 #1 SMP Tue Jun 16 23:23:21 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux

$ ps
Segmentation fault

$ top
Segmentation fault

$ sysctl 
Segmentation fault

$ grep "general protection" /var/log/messages | grep "Jul  9"
Jul  9 02:03:16 localhost kernel: sysctl[88] general protection ip:349e60ab2d sp:7fff8a16f3b8 error:0 in libproc-3.2.7.so[349e600000+e000]
Jul  9 02:03:16 localhost kernel: sysctl[845] general protection ip:349e60ab2d sp:7fff98302178 error:0 in libproc-3.2.7.so[349e600000+e000]
Jul  9 02:03:22 localhost kernel: sysctl[1281] general protection ip:349e60ab2d sp:7fff54ced548 error:0 in libproc-3.2.7.so[349e600000+e000]
Jul  9 12:19:40 localhost kernel: ps[1720] general protection ip:349e60ab2d sp:7ffff3fcb178 error:0 in libproc-3.2.7.so[349e600000+e000]
Jul  9 12:19:50 localhost kernel: ps[1722] general protection ip:349e60ab2d sp:7fffc149c0e8 error:0 in libproc-3.2.7.so[349e600000+e000]
Jul  9 12:19:59 localhost kernel: top[1723] general protection ip:349e60ab2d sp:7fff6a75a568 error:0 in libproc-3.2.7.so[349e600000+e000]
Jul  9 12:20:22 localhost kernel: top[1725] general protection ip:349e60ab2d sp:7fffc4d01e28 error:0 in libproc-3.2.7.so[349e600000+e000]
Jul  9 12:25:43 localhost kernel: sysctl[1728] general protection ip:349e60ab2d sp:7fffc3a8a188 error:0 in libproc-3.2.7.so[349e600000+e000]

Comment 6 Tomas Smetana 2009-07-09 11:27:29 UTC
Hello Marc,
  you can try to install the debuginfo packages ("debuginfo-install procps") and try to run ps with valgrind or gdb to get some more clues.

Note: I have changed the assignee to the recent maintainer.  I think this bug is worth investigating since it might show some more generic problem.  I'd like to help here if possible but the actual decision on reopening the bug is up to Dan.

Comment 7 Marc Schlensog 2009-07-09 11:59:31 UTC
Hi Dan,

that's already more than I expected :)

Here is the output for top (message is identical for the other programs that segfault):

Starting program: /usr/bin/top 

Program received signal SIGSEGV, Segmentation fault.
0x000000349e60ab2d in set_fast_math () at ../../../gcc/config/i386/crtfastmath.c:97
97	../../../gcc/config/i386/crtfastmath.c: No such file or directory.
	in ../../../gcc/config/i386/crtfastmath.c

Comment 8 Daniel Novotny 2009-07-09 13:04:57 UTC
hello Marc,
I tried to google "crtfastmath" and "set_fast_math" a bit and found this:

http://netdomination.org/~stkn/index.php?/archives/24-Anatomy-of-a-segfault....html

so I made a build of procps without the -ffastmath compile switch:
you can try it here:

http://koji.fedoraproject.org/koji/taskinfo?taskID=1463271

and see if it helps...

Comment 9 Marc Schlensog 2009-07-09 14:05:42 UTC
Hi Dan,

yes, that actually fixed it. Very cool :) That's more than I was expecting when I re-opened the bug.

Thanks and best regards,

Marc