From Bugzilla Helper: User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.2.19-7.0.12 i686) Description of problem: Using gcc-2.96-85, compiling with the gcc optimizer (i.e., -O, -O2, or -O3) AND generating debugging information (i.e., -g or -g3) produces bad startup code, whereas using just the optimizer alone or generating debug symbols alone is just fine. The bad startup code causes programs to Seg fault in startup code, prior to main. Version-Release number of selected component (if applicable): gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) How reproducible: Always Steps to Reproduce: 0.Use an AMD TBird CPU system (say on a SOYO Dragon motherboard) 1.fetch calc from http://www.isthe.com/chongo/src/calc/gcc-calc-bug.tar.gz 2.tar -zxvf gcc-calc-bug.tar 3.cd calc-2.11.5.5 4.make calc (observe that calc compiles with -O2) 5. ./calc 2+2 (observe that calc says 4 and exits) 6.make clobber 7.make calc DEBUG="-O -g" (observe that calc compiles with -O -g) 8. ./calc 2+2 (observe that calc dumps core, prior to running main) Actual Results: Calc produces a segmentation fault early in startup when compiled with -O -g: $ ./calc Segmentation fault (core dumped) $ gdb ./calc core ... Core was generated by `./calc'. Program terminated with signal 11, Segmentation fault. #0 0x2aab68a0 in ?? () (gdb) where #0 0x2aab68a0 in ?? () #1 0x2aaadaf5 in ?? () #2 0x2aabb197 in ?? () #3 0x2aaad441 in ?? () #4 0x2aaad233 in ?? () (gdb) break main Breakpoint 1 at 0x8049b89: file calc.c, line 100. (gdb) run Starting program: /usr/local/src/cmd/calc/./calc Program received signal SIGSEGV, Segmentation fault. 0x2aab68a0 in ?? () when performed on an AMD TBird CPU. NOTE: In the above gdb example, when calc was rerun, it died in the startup code prior to main. Expected Results: calc should not SEG fault in startup code prior to main. Use of -g or -g3 should not cause a program to dump core. Additional info: On AMD Althlon, non-TBird CPUs (CPUs without the 3DNow features) the -Ox -gx startup bug does not show up. It seems that one must be using the AMD Athlon Thunderbird CPU line to run into this bug. A simple "Hello, world" program does not trigger this bug, it seems that one must have a larger program with lots of symbols and what-nots on an AMD TBird to trigger this program ... otherwise I'd give you a smaller bug example. :-) :-( FYI: I'm using glibc-2.2.4-18.7.0.3 I'm running on a SOYO Dragon board with an AMD 1.4 GHz CPU. This bug appears under RH7.0 as well.
Cannot reproduce this either. Are you sure your hardware is ok? Can you try using an .i686.rpm kernel instead of .athlon.rpm one (or use noathlon).
Did you try it under RH7.0 or RH7.1 (with the latest RPM patches)? On RH7.0 for example the kernel was built with these processor type and features: CONFIG_M686=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y # CONFIG_1GB is not set CONFIG_2GB=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_SMP is not set What sort of CPU were you using? Here is the /proc/cpuinfo for a system on which -O -g dies in startup: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 4 model name : AMD Athlon(tm) processor stepping : 4 cpu MHz : 1396.557 cache size : 256 KB fdiv_bug : no hlt_bug : no sep_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 psn mmxext mmx fxsr 3dnowext 3dnow bogomips : 2785.28 How does that compare with the system on which you tested? Here is a /proc/cpuinfo on a non-TBird CPU for which -O -g does NOT fail in startup: processor : 0 vendor_id : AuthenticAMD cpu family : 6 model : 2 model name : AMD Athlon(tm) Processor stepping : 1 cpu MHz : 598.841 cache size : 512 KB fdiv_bug : no hlt_bug : no sep_bug : no f00f_bug : no coma_bug : no fpu : yes fpu_exception : yes cpuid level : 1 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmxext mmx fxsr 3dnowext 3dnow bogomips : 1192.75 Both are running: gcc version 2.96 20000731 (Red Hat Linux 7.1 2.96-85) glibc-profile-2.2.4-18.7.0.3 glib-devel-1.2.8-4 compat-glibc-6.2-2.1.3.2 glib10-1.0.6-9 glibc-devel-2.2.4-18.7.0.3 glibc-common-2.2.4-18.7.0.3 glib-1.2.8-4 glibc-2.2.4-18.7.0.3 gcc-c++-2.96-85 kgcc-1.1.2-40 gcc-2.96-85 gcc-objc-2.96-85 gcc-g77-2.96-85 Does that help?
> Are you sure your hardware is ok? The hardware tests are clean. I have had no crashes or CPU lockups. Ran CPU and disk heavy jobs for extended periods of time without any problems being detected (computational-wise or system crash/lockup-wise) > Can you try using an .i686.rpm kernel instead of .athlon.rpm one > (or use noathlon). I'm using kernel-2.2.19-7.0.12 with the CPU/Processor options as shown in the previous posting.
FYI: The same -O -g bug shows up under a 2.2.19-7.0.10 kernel ...
The bug seems to be triggered by use of readline. If calc is compiled without readline, all is OK and calc does not dump core prior to main. If calc is compiled with readline, then calc dumps core in startup. Take a look at this tarball: http://www.isthe.com/chongo/src/calc/gcc-readline-calc-bug.tar.gz The Makefile in the gcc-readline-calc-bug.tar.gz file has been changed to compile with readline. I also changed the default compile to use '-O -g". The calc binary was compiled under RH7.0 with: (I did a rpm -q -a | egrep 'gcc|libc|readline|curses' which printed out a few more RPMs that needed, but you should get the idea) ncurses-5.2-2 libc-5.3.12-31 gcc-2.96-85 glibc-common-2.2.4-18.7.0.3 readline-4.1-5 ncurses-devel-5.2-2 gcc-g77-2.96-85 gcc-c++-2.96-85 compat-glibc-6.2-2.1.3.2 ncurses4-5.0-2 readline2.2.1-2.2.1-2 glibc-2.2.4-18.7.0.3 glibc-profile-2.2.4-18.7.0.3 readline-devel-4.1-5 kgcc-1.1.2-40 gcc-objc-2.96-85 glibc-devel-2.2.4-18.7.0.3 on a 2.2.19-7.0.12 kernel. The core dump in that tarball shows the effect of the pre-main seg fault. =-= It is interesting to note that under the RH7.0 stock CD, this bug does not show up. Something that was updated (kernel? glibc? gcc?) changed the behaviour of calc when compiled with -O -g. Ideas?
Calc works with readline and -g3 and -O3 under RH7.3.