Description of problem: The python3-scipy tests are crashing here: python3 /usr/lib/python3.3/site-packages/scipy/linalg/tests/test_decomp.py generally with a segfault in some malloc related routine that points to memory corruption before that point. Version-Release number of selected component (if applicable): python3-scipy-0.11.0-3.fc18.i686 First valgrind error: valgrind python3 /usr/lib/python3.3/site-packages/scipy/linalg/tests/test_decomp.py ==17599== Memcheck, a memory error detector ==17599== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al. ==17599== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info ==17599== Command: python3 /usr/lib/python3.3/site-packages/scipy/linalg/tests/test_decomp.py ==17599== ..............==17599== Invalid write of size 8 ==17599== at 0x4F0E4913: dlacpy_ (in /usr/lib/atlas/liblapack.so.3.0) ==17599== by 0x4F15FD06: dsbevx_ (in /usr/lib/atlas/liblapack.so.3.0) ==17599== by 0x77D064E: f2py_rout_flapack_dsbevx (flapackmodule.c:25876) ==17599== by 0x77D8789: fortran_call (fortranobject.c:346) ==17599== by 0x4067C10: PyObject_Call (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x411BC7C: PyEval_EvalFrameEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x411E9F4: PyEval_EvalFrameEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x4120A23: PyEval_EvalCodeEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x411E6B1: PyEval_EvalFrameEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x4120A23: PyEval_EvalCodeEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x4091442: ??? (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x4067C10: PyObject_Call (in /usr/lib/libpython3.3m.so.1.0) ==17599== Address 0x68afda8 is 0 bytes after a block of size 80 alloc'd ==17599== at 0x4008F6F: malloc (vg_replace_malloc.c:270) ==17599== by 0x70CFF7A: ??? (in /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so) ==17599== by 0x70F8B1D: ??? (in /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so) ==17599== by 0x77D8D08: array_from_pyobj (fortranobject.c:630) ==17599== by 0x77D04A8: f2py_rout_flapack_dsbevx (flapackmodule.c:25854) ==17599== by 0x77D8789: fortran_call (fortranobject.c:346) ==17599== by 0x4067C10: PyObject_Call (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x411BC7C: PyEval_EvalFrameEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x411E9F4: PyEval_EvalFrameEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x4120A23: PyEval_EvalCodeEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x411E6B1: PyEval_EvalFrameEx (in /usr/lib/libpython3.3m.so.1.0) ==17599== by 0x4120A23: PyEval_EvalCodeEx (in /usr/lib/libpython3.3m.so.1.0) points to interaction with atlas.
Commenting out test_dsbevx in that file gets us farther. Now valgrind complains about: ==20207== Invalid write of size 8 ==20207== at 0x4F39BBD5: zlacpy_ (in /usr/lib/atlas/liblapack.so.3.0) ==20207== by 0x4F367812: zhbevx_ (in /usr/lib/atlas/liblapack.so.3.0) ==20207== by 0x77CD0ED: f2py_rout_flapack_zhbevx (flapackmodule.c:27055) Hmm, really doesn't like *bevx. Looks like these tests have some questions about the arguments? ## Achtung: Argumente 0.0,0.0,range? w, evec, num, ifail, info = zhbevx(self.bandmat_herm, 0.0, 0.0, 1, N, compute_v=1, range=2)
This looks to be the fix: https://github.com/scipy/scipy/pull/404/commits Building now...
scipy-0.11.0-4.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/FEDORA-2013-2421/scipy-0.11.0-4.fc18
Package scipy-0.11.0-4.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing scipy-0.11.0-4.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-2421/scipy-0.11.0-4.fc18 then log in and leave karma (feedback).
scipy-0.11.0-4.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.