[Numpy-discussion] Fwd: Package: scipy-0.11.0-0.1.rc2.fc18 Tag: f18-updates-candidate Status: failed Built by: orion
Orion Poplawski
orion at cora.nwra.com
Wed Feb 13 19:06:09 EST 2013
On 09/21/2012 11:41 AM, Ondřej Čertík wrote:
> Hi Orion,
>
> On Thu, Sep 20, 2012 at 2:56 PM, Orion Poplawski <orion at cora.nwra.com> wrote:
>> This is a plea for some help. We've been having trouble getting scipy to
>> pass all of the tests in the Fedora 18 build with python 3.3 (although it
>> seems to build okay in Fedora 19). Below are the logs of the build. There
>> appears to be some kind of memory corruption that manifests itself a little
>> differently on 32-bit vs. 64-bit. I really have no idea myself how to
>> pursue debugging this, though I'm happy to provide any more needed
>> information.
>
> Thanks for testing the latest beta2 release.
>
>> Task 4509077 on buildvm-35.phx2.fedoraproject.org
>> Task Type: buildArch (scipy-0.11.0-0.1.rc2.fc18.src.rpm, i686)
>> logs:
>> http://koji.fedoraproject.org/koji/getfile?taskID=4509077&name=build.log
>
> This link has the following stacktrace:
>
> /lib/libpython3.3m.so.1.0(PyMem_Free+0x1c)[0xbf044c]
> /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0x4d52b)[0x42252b]
> /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0xcb7c5)[0x4a07c5]
> /usr/lib/python3.3/site-packages/numpy/core/multiarray.cpython-33m.so(+0xcbc5e)[0x4a0c5e]
>
> Which indeed looks like in NumPy. Would you be able to obtain full stacktrace?
>
> There has certainly been segfaults in Python 3.3 with NumPy, but we've
> fixed all that we could reproduce. That doesn't mean there couldn't be
> more. If you could nail it down a little bit more, that would be
> great. I'll help once I can reproduce it somehow.
>
> Ondrej
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
Trying to get back to this as we still see it with numpy 1.7.0 and scipy 0.11.
I'm seeing a segfault in malloc_consolidate(), which seems like would only
occur if there were problems earlier, so I'm not sure a stack trace is all
that useful.
Starting program: /usr/bin/python3
/export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/tests/test_decomp.py
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
..............
Program received signal SIGSEGV, Segmentation fault.
0x0000003d8d67bdad in malloc_consolidate (av=av at entry=0x3d8d9b1740 <main_arena>)
at malloc.c:4151
4151 unlink(av, nextchunk, bck, fwd);
Here's some:
#0 0x0000003d8d67bdad in malloc_consolidate (av=av at entry=0x3d8d9b1740
<main_arena>)
at malloc.c:4151
#1 0x0000003d8d67d09e in _int_malloc (av=0x3d8d9b1740 <main_arena>,
bytes=<optimized out>)
at malloc.c:3422
#2 0x0000003d8d67f443 in __GI___libc_malloc (bytes=2632) at malloc.c:2862
#3 0x00007ffff121816c in PyArray_IterNew (obj=<numpy.ndarray at remote 0xe02fd0>)
at numpy/core/src/multiarray/iterators.c:385
#4 0x00007ffff1218201 in PyArray_IterAllButAxis (obj=obj at entry=
<numpy.ndarray at remote 0xe02fd0>, inaxis=inaxis at entry=0x7fffffff873c)
at numpy/core/src/multiarray/iterators.c:488
#5 0x00007ffff1257970 in _new_argsort (which=NPY_QUICKSORT, axis=0, op=0xe02fd0)
at numpy/core/src/multiarray/item_selection.c:815
#6 PyArray_ArgSort (op=op at entry=0xe02fd0, axis=0, which=NPY_QUICKSORT)
at numpy/core/src/multiarray/item_selection.c:1104
#7 0x00007ffff125873a in array_argsort (self=0xe02fd0, args=<optimized out>,
kwds=<optimized out>) at numpy/core/src/multiarray/methods.c:1213
#8 0x0000003b74d0cc8e in call_function (oparg=<optimized out>,
pp_stack=0x7fffffff8998)
at /usr/src/debug/Python-3.3.0/Python/ceval.c:4091
#9 PyEval_EvalFrameEx (f=f at entry=
Frame 0xd3ecb0, for file
/usr/lib64/python3.3/site-packages/numpy/core/fromnumeric.py, line 681, in
argsort (a=<numpy.ndarray at remote 0xe02fd0>, axis=-1, kind='quicksort',
order=None, argsort=<built-in method argsort of numpy.ndarray object at remote
0xe02fd0>),
throwflag=throwflag at entry=0) at
/usr/src/debug/Python-3.3.0/Python/ceval.c:2703
#10 0x0000003b74d0de63 in PyEval_EvalCodeEx (_co=_co at entry=<code at remote
0x7ffff1a8ac00>,
globals=<optimized out>, locals=locals at entry=0x0, args=<optimized out>,
argcount=argcount at entry=1, kws=0xe23ab8, kwcount=kwcount at entry=0,
defs=0x7ffff1a965b8,
defcount=3, kwdefs=0x0, closure=0x0) at
/usr/src/debug/Python-3.3.0/Python/ceval.c:3462
#11 0x0000003b74d0c707 in fast_function (nk=0, na=1, n=<optimized out>, pp_stack=
0x7fffffff8c88, func=<function at remote 0x7ffff1160320>)
at /usr/src/debug/Python-3.3.0/Python/ceval.c:4189
#12 call_function (oparg=<optimized out>, pp_stack=0x7fffffff8c88)
at /usr/src/debug/Python-3.3.0/Python/ceval.c:4112
(gdb) up 3
#3 0x00007ffff121816c in PyArray_IterNew (obj=<numpy.ndarray at remote 0xe02fd0>)
at numpy/core/src/multiarray/iterators.c:385
385 it = (PyArrayIterObject *)PyArray_malloc(sizeof(PyArrayIterObject));
(gdb) print *obj
$4 = {ob_refcnt = 5, ob_type = 0x7ffff14c6900 <PyArray_Type>}
(gdb) list
380 PyErr_BadInternalCall();
381 return NULL;
382 }
383 ao = (PyArrayObject *)obj;
384
385 it = (PyArrayIterObject *)PyArray_malloc(sizeof(PyArrayIterObject));
386 PyObject_Init((PyObject *)it, &PyArrayIter_Type);
387 /* it = PyObject_New(PyArrayIterObject, &PyArrayIter_Type);*/
388 if (it == NULL) {
389 return NULL;
valgrind reports problems like:
==10886== Invalid write of size 8
==10886== at 0x3D9C5CB576: dlacpy_ (in /usr/lib64/atlas/liblapack.so.3.0)
==10886== by 0x3D9C6481F7: dsbevx_ (in /usr/lib64/atlas/liblapack.so.3.0)
==10886== by 0x115D8212: ??? (in
/export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so)
==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082)
==10886== by 0x3B74D07DDC: PyEval_EvalFrameEx (ceval.c:4311)
==10886== by 0x3B74D0C9B4: PyEval_EvalFrameEx (ceval.c:4179)
==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462)
==10886== by 0x3B74D0C706: PyEval_EvalFrameEx (ceval.c:4189)
==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462)
==10886== by 0x3B74C8547F: function_call (funcobject.c:633)
==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082)
==10886== by 0x3B74D05F7F: PyEval_EvalFrameEx (ceval.c:4406)
==10886== Address 0xbbc8cd0 is 0 bytes after a block of size 80 alloc'd
==10886== at 0x4A0883C: malloc (vg_replace_malloc.c:270)
==10886== by 0xE8A103A: PyDataMem_NEW (multiarraymodule.c:3492)
==10886== by 0xE8C3F74: PyArray_NewFromDescr (ctors.c:970)
==10886== by 0x115E032B: array_from_pyobj (in
/export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so)
==10886== by 0x115D7F5E: ??? (in
/export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so)
==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082)
==10886== by 0x3B74D07DDC: PyEval_EvalFrameEx (ceval.c:4311)
==10886== by 0x3B74D0C9B4: PyEval_EvalFrameEx (ceval.c:4179)
==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462)
==10886== by 0x3B74D0C706: PyEval_EvalFrameEx (ceval.c:4189)
==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462)
==10886== by 0x3B74C8547F: function_call (funcobject.c:633)
==10886==
==10886== Invalid read of size 8
==10886== at 0x3D9C61DAD5: dlasr_ (in /usr/lib64/atlas/liblapack.so.3.0)
==10886== by 0x3D9C663092: dsteqr_ (in /usr/lib64/atlas/liblapack.so.3.0)
==10886== by 0x3D9C648290: dsbevx_ (in /usr/lib64/atlas/liblapack.so.3.0)
==10886== by 0x115D8212: ??? (in
/export/home/orion/redhat/BUILDROOT/scipy-0.11.0-3.fc19.x86_64/usr/lib64/python3.3/site-packages/scipy/linalg/flapack.cpython-33m.so)
==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082)
==10886== by 0x3B74D07DDC: PyEval_EvalFrameEx (ceval.c:4311)
==10886== by 0x3B74D0C9B4: PyEval_EvalFrameEx (ceval.c:4179)
==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462)
==10886== by 0x3B74D0C706: PyEval_EvalFrameEx (ceval.c:4189)
==10886== by 0x3B74D0DE62: PyEval_EvalCodeEx (ceval.c:3462)
==10886== by 0x3B74C8547F: function_call (funcobject.c:633)
==10886== by 0x3B74C5EF8E: PyObject_Call (abstract.c:2082)
==10886== Address 0xbbc8dc0 is not stack'd, malloc'd or (recently) free'd
So perhaps an atlas issue, or the way scipy/numpy calls it. I'll try to look
into it more. Suggestions welcome.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder Office FAX: 303-415-9702
3380 Mitchell Lane orion at nwra.com
Boulder, CO 80301 http://www.nwra.com
More information about the NumPy-Discussion
mailing list