Bug 185217

Summary:	octave crashes with illegal instruction when run on i586
Product:	[Fedora] Fedora	Reporter:	Quentin Spencer <qspencer>
Component:	hdf5	Assignee:	Orion Poplawski <orion>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	jakub, qspencer
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:	1.6.5-4.fc5	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2006-03-13 21:19:39 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 Quentin Spencer 2006-03-12 00:15:22 UTC

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):
gcc-4.0.2-8 (FC4)
gcc-4.1.0-3 (Rawhide)

How reproducible:
Always


Steps to Reproduce:
1. Run octave on a Pentium or K6 processor (possibly others)
2. In octave, run the following commands:

octave:1> a=1;
octave:2> save testfile.txt a
octave:3> load testfile.txt


Actual results:
panic: Illegal instruction -- stopping myself...
attempting to save variables to `octave-core'...
save to `octave-core' complete
Illegal instruction


Expected results:
Return to octave prompt, having successfully loaded the file.

Comment 1 Jakub Jelinek 2006-03-12 07:27:36 UTC

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.

Comment 2 Quentin Spencer 2006-03-12 15:52:41 UTC

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:

#include "hdf5.h"

int main()
{
  return H5Fis_hdf5("hdf5test.c");
}


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.

Comment 3 Jakub Jelinek 2006-03-13 10:16:31 UTC

0007fae4 <H5I_init_group>:
   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.
hdf5-1.6.5/config/gnu-flags
hdf5-1.6.5/fortran/config/gnu-flags
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.