Red Hat Bugzilla – Bug 185217
octave crashes with illegal instruction when run on i586
Last modified: 2007-11-30 17:11:27 EST
Description of problem:
Loading saved data files in Octave from Fedora Extras crashes with an illegal
instruction when run on older processors. This should not happen since
everything in Core and Extras is compiled with "-march=i386". This was
originally reported by a user on the octave mailing list who discovered it on a
K6-3 processor. I was able to duplicate this on a Pentium MMX, but not on a
Centrino laptop (I think that's roughly equivalent to a P-III, right?). That's
all the test cases I can report so far. This was originally reported on the FC4
version of octave that was compiled February 1, which would probably have been
compiled with the current release (gcc-4.0.2-8) or the one before. However, the
P-MMX case I refered to was on a rawhide system (with a different octave version
as well) and would have been compiled February 15 with one of the latest gcc-4.1
releases. I also did a test build of the FC4 version of Octave locally on my
P-MMX rawhide system yesterday (gcc-4.1.0-3) and that version also crashed in
the same way.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Run octave on a Pentium or K6 processor (possibly others)
2. In octave, run the following commands:
octave:2> save testfile.txt a
octave:3> load testfile.txt
panic: Illegal instruction -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Return to octave prompt, having successfully loaded the file.
Non-i586 instructions can make it into the binary or libraries it uses in many
ways, of course I won't rule out GCC's fault now, but it is orders of magnitude
less probable than octave or one of its dependencies compiled with e.g.
-msse, -msse2, -mfpmath=sse, -march=i686, using inline asm with SSE etc. code
or using assembly sources with the same.
You need to find out which instruction was it, from which library (or octave main
binary?) and in which routine, then look around if there is assembly used and/or
with what flags that routine was compiled with.
OK, I have narrowed this down a little. The error occurs in the hdf5 library
(also from Extras). The following test program will trigger the illegal instruction:
compiling this with "gcc -o hdf5test -lhdf5 hdf5test.c" and running gives an
illegal instruction. In gdb the error message says it occurs at:
0x00192353 in H5I_init_group () from /usr/lib/libhdf5.so.0
I looked at the spec file for compiling hdf5 and it is configured using the
%configure macro, which would seem to imply that it is compiled with the
-march=i386 flag. I don't believe there is any inline assembly in the library.
7fae4: 55 push %ebp
7fae5: 57 push %edi
7fae6: 56 push %esi
7fae7: 53 push %ebx
7fae8: 83 ec 1c sub $0x1c,%esp
7faeb: e8 34 2d f9 ff call 12824 <__i686.get_pc_thunk.bx>
7faf0: 81 c3 14 d1 0b 00 add $0xbd114,%ebx
7faf6: 8b 6c 24 30 mov 0x30(%esp),%ebp
7fafa: 8b 74 24 34 mov 0x34(%esp),%esi
7fafe: 83 bb 3c 18 00 00 00 cmpl $0x0,0x183c(%ebx)
7fb05: b8 01 00 00 00 mov $0x1,%eax
7fb0a: 0f 45 83 3c 18 00 00 cmovne 0x183c(%ebx),%eax
Of course cmovne is i686+ insn.
The bug is in hdf5 configury apparently, see e.g.
It does a very stupid thing - sets -march= depending on uname -m.
Instead the src.rpm should patch it to use $RPM_OPT_FLAGS (if really needed
and src/H5Tconv.c breaks strict aliasing, $RPM_OPT_FLAGS can be overridden
e.g. with -O instead of -O2 in it by using "$RPM_OPT_FLAGS -O" or better yet
"$RPM_OPT_FLAGS -fno-strict-aliasing" if that works.