Bug 49484 - gcc randomly fails with Illegal Instruction error
gcc randomly fails with Illegal Instruction error
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: gcc (Show other bugs)
7.1
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-07-19 20:27 EDT by Jason Rothstein
Modified: 2007-04-18 12:34 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-07-29 21:32:38 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
MySQL 3.23.39 (10.68 MB, application/octet-stream)
2001-07-20 11:25 EDT, Jason Rothstein
no flags Details

  None (edit)
Description Jason Rothstein 2001-07-19 20:27:16 EDT
Description of Problem:

gcc-2.96-85 miscompiles MySQL 3.23.39 randomly on RH7.1 with all current 
erratta applied. Stock RH7.1 without errata applied will compile it fine.

CPU is K6-2/500 on Gigabyte GA-5AA with 192MB RAM.

How Reproducible:

5 Attempts to reproduce this have the error appear in different source 
files thus far. Using MySQL-3.23.36 RPM with a version update to 3.23.39 
and enabling thread safe client, assembler versions of functions, raid, 
libwrap, and innodb from the orignal causes the problem. Building the rpm 
with "rpm -ba --clean --rmsource --rmspec mysql.spec" shows problem.

Steps to Reproduce:
1. Install RH7.1 with all errata as of 19 Jul 2001
2. DL MySQL 3.23.39
3. install MySQL 3.23.36 Source rpm
4. Modify version number
5. Add --enable-thread-safe-client --enable-assembler --with-raid --with-
innodb to the configure line
6. rpm -ba --clean --rmsource --rmspec mysql.spec

Actual Results:

gcc -DDEFAULT_CHARSET_HOME=\"/usr\" -DDATADIR=\"/var/lib/mysql\" -
DSHAREDIR=\"/usr/share/mysql\" -I./../include -I../include -I./.. -I.. -
I.. -O3 -DDBUG_OFF -O2 -march=i386 -mcpu=i686 -c safemalloc.c  -fPIC -
DPIC -o .libs/safemalloc.lo
In file included from /usr/include/math.h:350,
                 from ../include/global.h:164,
                 from mysys_priv.h:18,
                 from safemalloc.c:71:
/usr/include/bits/mathinline.h: In function `__sgnf':
/usr/include/bits/mathinline.h:291: Internal error: Illegal instruction.
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make[2]: *** [safemalloc.lo] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/mysql-3.23.39/libmysql_r'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/mysql-3.23.39'
make: *** [all-recursive-am] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.9354 (%build)


Expected Results:

A set of working MySQL RPMs tossed into the /usr/src/redhat/RPMS/i386/ 
directory

Additional Information:
	
Reproducable on Single and Dual Pentium III, Single Athlon Classic, and 
Dual Celeron machines so far.
Comment 1 Jakub Jelinek 2001-07-20 08:32:44 EDT
Can you reproduce it on vanilla RHL 7.1 just with gcc-2.96-85?
Can you attach the src.rpm you're trying to build (e.g. using rpm -bs)?
Compiler is a deterministic program, so you should be able to reproduce
a bug either all the time on the same file, or never. Random bugs
which go away next time usually mean either hardware bugs, or kernel bugs.
Comment 2 Jason Rothstein 2001-07-20 11:25:28 EDT
Created attachment 24307 [details]
MySQL 3.23.39
Comment 3 Jason Rothstein 2001-07-23 22:30:11 EDT
That particular computer K6-2/500 seems to love to error out of pretty much 
everything right now (autorpm perl application sigsegvs and/or dumps core, and 
other applications randomly dump core). Machine in question was recently 
reinstalled from a RH Beta Fisher install which was working without errors.

Since the K6-2 CPU is a i586 class CPU could the build instructions generated 
by RPM "gcc -O2 -march=i386 -mcpu=i686" cause invalid code to be generated 
that could cause this problem in a similar fashion to what happened during the 
RH 5.x series when the compiler was compiled with -O instead of -O2 thus 
causing invalid code to be generated in the compiler on Cyrix CPU's?

Athlon 700 i have tried what you suggested on has no problems. I need to find 
my Pentium machine and other K6-2 to see if it duplicates in other similar 
i586 class architectures.

I'm also playing with the rawhide gcc right now to see if I can duplicate with 
that one.
Comment 4 Jakub Jelinek 2001-07-24 05:46:36 EDT
-march=i386 -mcpu=i686 does not generate any instructions which should cause
problems to K6-2, the difference between that and simple -march=i386 is
just instruction scheduling and which instructions from i386 ISA are preferred
over others.
Waiting if you find something reproducible.
Comment 5 Jason Rothstein 2001-07-29 20:18:44 EDT
Ok, I have Pentium 90 installed with RH 7.1 plus GCC/CPP/libstdc++ errata only. 
It will compile MySQL 3.23.40 out of RawHide correctly and PHP from RH7.1 
correctly. both will run correctly. (Getting PHP to compile after all errata 
was applied was another issue of mine but mysql first...)

I have re-installed the AMD K6-2/500 with vanilla RH7.1 and it is happy now 
without any problems (no more random Sig11's and the like during compiles). I'm 
currently appling the GCC/CPP/libstdc++ errata to it to see about duplication.
Comment 6 Jason Rothstein 2001-07-29 21:22:22 EDT
K6-2/500 machine with only the gcc/cpp/libstdc++ errata applied produces the 
following while building mysql-3.23.40-1.src.rpm from rawhide:

gcc -DDEFAULT_CHARSET_HOME=\"/usr\" -DDATADIR=\"/var/lib/mysql\" -
DSHAREDIR=\"/usr/share/mysql\" -DUNDEF_THREADS_HACK -I./../include -
I../include -I./.. -I.. -I.. -O3 -DDBUG_OFF -O2 -march=i386 -mcpu=i686 -
D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -c my_open.c  -fPIC -
DPIC -o .libs/my_open.lo
In file included from /usr/include/math.h:350,
                 from ../include/global.h:164,
                 from mysys_priv.h:18,
                 from my_open.c:19:
/usr/include/bits/mathinline.h: In function `log1pl':
/usr/include/bits/mathinline.h:540: Internal error: Segmentation fault.
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make[2]: *** [my_open.lo] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/mysql-3.23.40/libmysql'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/mysql-3.23.40'
make: *** [all-recursive-am] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.82722 (%build)


Now i'm going to back out of the gcc/cpp/libstdc++ errata and go back to the 
distro CD versions and see what happens....
Comment 7 Jason Rothstein 2001-07-29 21:30:12 EDT
With vanilla GCC shiped on 7.1 CD's... this is what mysql-3.23.40-1.src.rpm 
does on building on K6-2/500

Making all in client
make[2]: Entering directory `/usr/src/redhat/BUILD/mysql-3.23.40/client'
c++ -DUNDEF_THREADS_HACK -I./../include                                 -
I../include -I./.. -I..                                -I..    -O3 -DDBUG_OFF -
O2 -march=i386 -mcpu=i686 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -
D_LARGEFILE_SOURCE  -fno-implicit-templates -fno-exceptions -fno-rtti -c 
mysql.cc
mysql.cc: In function `bool add_line (String &, char *, char *)':
mysql.cc:1012: Internal error: Segmentation fault.
Please submit a full bug report.
See <URL:http://bugzilla.redhat.com/bugzilla/> for instructions.
make[2]: *** [mysql.o] Error 1
make[2]: Leaving directory `/usr/src/redhat/BUILD/mysql-3.23.40/client'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/src/redhat/BUILD/mysql-3.23.40'
make: *** [all-recursive-am] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.73293 (%build)

Begining to think something is up with this K6-2/500's MB now as I see the 
following in the logs from last night:

Jul 29 04:06:21 draco kernel: Unable to handle kernel paging request at virtual 
address 2f14244c
Jul 29 04:06:21 draco kernel:  printing eip:
Jul 29 04:06:21 draco kernel: c012220f
Jul 29 04:06:21 draco kernel: pgd entry c434e2f0: 0000000000000000
Jul 29 04:06:21 draco kernel: pmd entry c434e2f0: 0000000000000000
Jul 29 04:06:21 draco kernel: ... pmd not present!
Jul 29 04:06:21 draco kernel: Oops: 0000
Jul 29 04:06:21 draco kernel: CPU:    0
Jul 29 04:06:21 draco kernel: EIP:    0010:[zap_page_range+175/720]
Jul 29 04:06:21 draco kernel: EIP:    0010:[<c012220f>]
Jul 29 04:06:21 draco kernel: EFLAGS: 00010287
Jul 29 04:06:21 draco kernel: eax: 00015000   ebx: 40000000   ecx: c434e400   
edx: c434e400
Jul 29 04:06:21 draco kernel: esi: 40015000   edi: 00015000   ebp: 00000000   
esp: c035fe58
Jul 29 04:06:21 draco kernel: ds: 0018   es: 0018   ss: 0018
Jul 29 04:06:21 draco kernel: Process zcat (pid: 27564, stackpage=c035f000)
Jul 29 04:06:21 draco kernel: Stack: 00000000 c32362a0 00052000 00000000 
00015000 c434e400 00000000 40015000
Jul 29 04:06:21 draco kernel:        c434e400 00000029 cb835b00 c011c066 
cb835b00 c035fedc 00000000 cb835b20
Jul 29 04:06:21 draco kernel:        00000006 00000010 00000000 3b63d20d 
00000246 c8351720 00015000 ca50fa00
Jul 29 04:06:21 draco kernel: Call Trace: [do_acct_process+518/544] 
[exit_mmap+177/288] [mmput+45/80] [do_exit+190/576] [dequeue_sig
nal+109/192] [do_signal+539/656] [sys_write+194/208]
Jul 29 04:06:21 draco kernel: Call Trace: [<c011c066>] [<c0124a11>] 
[<c0114d9d>] [<c0118b5e>] [<c011dafd>] [<c0108e4b>] [<c0133262>]

Jul 29 04:06:21 draco kernel:        [do_softirq+82/128] [signal_return+20/32]
Jul 29 04:06:21 draco kernel:        [<c0119d82>] [<c0109004>]
Jul 29 04:06:21 draco kernel:
Jul 29 04:06:21 draco kernel: Code: 31 c0 8b 11 29 ef 85 d2 0f 84 5d 01 00 00 
89 d0 25 fb 0f 00
Jul 29 04:06:24 draco kernel: Unable to handle kernel paging request at virtual 
address f719844c
Jul 29 04:06:24 draco kernel:  printing eip:
Jul 29 04:06:24 draco kernel: c012220f
Jul 29 04:06:24 draco kernel: pgd entry cb89af70: 0000000000000000
Jul 29 04:06:24 draco kernel: pmd entry cb89af70: 0000000000000000
Jul 29 04:06:24 draco kernel: ... pmd not present!
Jul 29 04:06:24 draco kernel: Oops: 0000
Jul 29 04:06:24 draco kernel: CPU:    0
Jul 29 04:06:24 draco kernel: EIP:    0010:[zap_page_range+175/720]
Jul 29 04:06:24 draco kernel: EIP:    0010:[<c012220f>]
Jul 29 04:06:24 draco kernel: EFLAGS: 00010287
Jul 29 04:06:24 draco kernel: eax: 000a8000   ebx: 08056000   ecx: cb89a080   
edx: cb89a080
Jul 29 04:06:24 draco kernel: esi: 080a8000   edi: 000a8000   ebp: 00056000   
esp: c035fef8
Jul 29 04:06:24 draco kernel: ds: 0018   es: 0018   ss: 0018
Jul 29 04:06:24 draco kernel: Process zcat (pid: 27695, stackpage=c035f000)
Jul 29 04:06:24 draco kernel: Stack: 00000000 c533d158 00002000 00000000 
000a8000 cb89a080 00000000 080a8000
Jul 29 04:06:24 draco kernel:        cb89a080 00000029 cb835b00 c011c066 
cb835b00 c035ff7c 00000000 cb835b20
Jul 29 04:06:24 draco kernel:        00000001 00000000 00000000 3b63d210 
00000202 caaabfa0 00052000 ca50fbe0
Jul 29 04:06:24 draco kernel: Call Trace: [do_acct_process+518/544] 
[exit_mmap+177/288] [mmput+45/80] [do_exit+190/576] [do_page_fau
lt+0/1152] [system_call+51/64]
Jul 29 04:06:24 draco kernel: Call Trace: [<c011c066>] [<c0124a11>] 
[<c0114d9d>] [<c0118b5e>] [<c0113100>] [<c0108fb3>]
Jul 29 04:06:24 draco kernel:
Jul 29 04:06:24 draco kernel: Code: 31 c0 8b 11 29 ef 85 d2 0f 84 5d 01 00 00 
89 d0 25 fb 0f 00
Jul 29 04:07:17 draco kernel: Unable to handle kernel paging request at virtual 
address f705614c
Jul 29 04:07:17 draco kernel:  printing eip:
Jul 29 04:07:17 draco kernel: c012220f
Jul 29 04:07:17 draco kernel: pgd entry c0ed4f70: 0000000000000000
Jul 29 04:07:17 draco kernel: pmd entry c0ed4f70: 0000000000000000
Jul 29 04:07:17 draco kernel: ... pmd not present!
Jul 29 04:07:17 draco kernel: Oops: 0000
Jul 29 04:07:17 draco kernel: CPU:    0
Jul 29 04:07:17 draco kernel: EIP:    0010:[zap_page_range+175/720]
Jul 29 04:07:17 draco kernel: EIP:    0010:[<c012220f>]
Jul 29 04:07:17 draco kernel: EFLAGS: 00010287
Jul 29 04:07:17 draco kernel: eax: 000a7000   ebx: 08056000   ecx: c0ed4080   
edx: c0ed4080
Jul 29 04:07:17 draco kernel: esi: 080a7000   edi: 000a7000   ebp: 00056000   
esp: c0c3bef8
Jul 29 04:07:17 draco kernel: ds: 0018   es: 0018   ss: 0018
Jul 29 04:07:17 draco kernel: Process zcat (pid: 29160, stackpage=c0c3b000)
Jul 29 04:07:17 draco kernel: Stack: 00000000 c0fa4158 00002000 00000000 
000a7000 c0ed4080 00000000 080a7000 
Jul 29 04:07:17 draco kernel:        c0ed4080 00000028 cb835b00 c011c066 
cb835b00 c0c3bf7c 00000000 cb835b20 
Jul 29 04:07:17 draco kernel:        00000001 00000000 00000000 3b63d245 
00000202 cb4ab9a0 00051000 ca50ff00 
Jul 29 04:07:17 draco kernel: Call Trace: [do_acct_process+518/544] 
[exit_mmap+177/288] [mmput+45/80] [do_exit+190/576] [do_page_fau
lt+0/1152] [system_call+51/64] 
Jul 29 04:07:17 draco kernel: Call Trace: [<c011c066>] [<c0124a11>] 
[<c0114d9d>] [<c0118b5e>] [<c0113100>] [<c0108fb3>] 
Jul 29 04:07:17 draco kernel: 
Jul 29 04:07:17 draco kernel: Code: 31 c0 8b 11 29 ef 85 d2 0f 84 5d 01 00 00 
89 d0 25 fb 0f 00 

and the following on the console only:



Red Hat Linux release 7.1 (Seawolf)
Kernel 2.4.2-2 on an i586

draco login: probable hardware bug: clock timer configuration lost - probably a 
VIA686a motherboard.
probable hardware bug: restoring chip configuration.
probable hardware bug: clock timer configuration lost - probably a VIA686a 
motherboard.
probable hardware bug: restoring chip configuration.


Comment 8 Jason Rothstein 2001-07-29 21:32:33 EDT
Those kernel panics are from when GCC is compiling MySQL... tried to compile 
again and watched it appear on the console and the logs.
Comment 9 Jakub Jelinek 2001-08-09 07:33:43 EDT
If you get kernel oopses while compiling MySQL, it is even better sign of
flaky hardware. No bugs in gcc would cause kernel oops.

Note You need to log in before you can comment on or make changes to this bug.