Bug 236334 - scipy.integrate.quad, Illegal instruction on i386 (recompilation helps)
scipy.integrate.quad, Illegal instruction on i386 (recompilation helps)
Product: Fedora
Classification: Fedora
Component: scipy (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jef Spaleta
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2007-04-13 05:00 EDT by Jan Martinek
Modified: 2007-11-30 17:12 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-15 16:15:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Martinek 2007-04-13 05:00:03 EDT
Description of problem:
scipy.integrate.quad crashes with "Illegal instruction". But only on i386
architecture. The solution is rebuilding the package from src.rpm. On x86_64 it
works fine.

Version-Release number of selected component (if applicable):
scipy-0.5.2-1.fc6, Build Date: Sun 25 Feb 2007 08:38:09 PM CET

How reproducible:

Steps to Reproduce:
cut and paste this code to your terminal:

python << EOF
from scipy.integrate import quad
from math import pi,cos

def ft(t):
    return cos(t)/(1 + 0.5*cos(t))**1.5
print quad(ft, 0, 2*pi)[0]

Actual results: 
On i386: Illegal instruction
On x86_64: -3.22295889217

Expected results:

Additional info: I tried
rpmbuild --rebuild scipy-0.5.2-1.fc7.src.rpm
and the resulting package is functional.
Comment 1 Jef Spaleta 2007-04-13 16:41:28 EDT
Okay I can definitely confirm the problem on fc6.  The problem does not exist on
fc7 for me. 

The fact that recompiling seems to help, seems to suggest to me that something
in the underlying libraries in fc6 have changed. Has there been a numpy, atlas,
blas or fftw update for fc6 since the latest scipy package was released?

I'm going to do some more local testing here and try to confirm if a rebuild
under mock works.  The problem with doing a local rpmbuild --rebuild is that you
aren't using the same environment as the buildsystem. This could be a subtle
buildsystem environment issue.

Comment 2 Jef Spaleta 2007-04-13 17:38:29 EDT
Okay a simple local rebuild under mock does not fix the problem for me.

Can you capture the output from your local rpmbuild session and attach it to
this bug report.  I need to understand what is different in your local
environment from that of the mock based build environment.

Comment 3 Jef Spaleta 2007-04-13 17:51:40 EDT
Okay, confirmed, on an fc6 box running rpmbuild --rebuild  gives me a working
package.  But running a local mock build of the package does not fix the problem.

So this must be a subtle issue with the buildsystem environment compared to a
local default user environment.  Hopefully I can figure this out, though any
help would be appreciated.

Comment 4 Jef Spaleta 2007-04-14 06:50:11 EDT
Okay i think i figured out what was going wrong. Scipy relies heavily on the
distutils module in numpy to build optimal fortran compiler flags dynamically. 
Optimal to numpy means, cpu specific. So what was happening was the binaries
were being built with optional instruction sets available on the buildserver's
cpus, but not available on all cpus. 

I'm going to be doing some local test builds on my machines over the weekend to
make sure I've nailed the problem and that I'm setting a reasonable set of
compiler options. I'll write back with location for test packages for you to try
out today or tomorrow.

Comment 5 Jef Spaleta 2007-04-14 14:55:20 EDT
I think I fixed it.
Can you please test the binary i built locally:

If this binary works for you, I'll go ahead and submit it to the buildsystem as
an update.

Comment 6 Jef Spaleta 2007-04-15 16:15:13 EDT
Okay scipy-0.5.2-1.1.fc6 has been built and is awaiting signing for release to
fc6-extras. Please test this package when it becomes available for download and
re-open if the problem persists.

Comment 7 Jan Martinek 2007-04-16 16:23:29 EDT

thank you very much for what you have done. I downloaded and installed the rpm
package you built and it does not contain the error anymore. Great!

Jan Martinek

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