Bug 770857 - Type-converting ufunc calls corrupt memory, leading to segfaults
Summary: Type-converting ufunc calls corrupt memory, leading to segfaults
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: numpy
Version: 16
Hardware: i686
OS: Linux
unspecified
high
Target Milestone: ---
Assignee: Gwyn Ciesla
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-12-29 17:27 UTC by Peter Williams
Modified: 2012-02-10 00:52 UTC (History)
6 users (show)

Fixed In Version: numpy-1.6.1-2.fc16
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-02-10 00:52:43 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Test case demonstrating the bug (308 bytes, text/x-python)
2011-12-29 17:27 UTC, Peter Williams
no flags Details

Description Peter Williams 2011-12-29 17:27:07 UTC
Created attachment 549978 [details]
Test case demonstrating the bug

In the Fedora 16 version of Numpy, ufunc calls with automatic type conversions
corrupt memory (a simple test case is below). These calls worked fine in the Fedora 14 build/version of Numpy. The crashes happen every time.

Version-Release number of selected component (if applicable):

numpy-1.6.0-2.1.fc16.i686
python-2.7.2-5.2.fc16.i686

Steps to Reproduce:
1. Run attached test case
  
When I run similar code in valgrind, I get the following complaint:

==18467== Invalid write of size 8
==18467==    at 0x4F645D3: DOUBLE_multiply (loops.c.src:1145)
==18467==    by 0x4F68E5E: PyUFunc_GenericFunction (ufunc_object.c:1945)
==18467==    by 0x4F69532: ufunc_generic_call (ufunc_object.c:4180)
==18467==    by 0x414441B4: PyObject_Call (in /usr/lib/libpython2.7.so.1.0)
==18467==    by 0x414DEABE: PyEval_EvalFrameEx (in /usr/lib/libpython2.7.so.1.0)
...
==18467==  Address 0x13232108 is 0 bytes after a block of size 65,536 alloc'd
==18467==    at 0x4007D89: malloc (vg_replace_malloc.c:236)
==18467==    by 0x41484F47: PyMem_Malloc (in /usr/lib/libpython2.7.so.1.0)
==18467==    by 0x4E7833C: npyiter_allocate_buffers (nditer.c.src:5211)
==18467==    by 0x4E78403: NpyIter_ResetBasePointers (nditer.c.src:1236)
==18467==    by 0x4F68D9E: PyUFunc_GenericFunction (ufunc_object.c:1923)
==18467==    by 0x4F3887F: ??? (in /usr/lib/python2.7/site-packages/numpy/core/multiarray.so)

So it appears that Numpy is writing beyond the bounds of the destination array.

Comment 1 Gwyn Ciesla 2012-01-31 16:30:55 UTC
Have you tested this against 1.6.1, in rawhide?

Comment 2 Peter Williams 2012-02-01 07:21:13 UTC
I installed the rawhide versions of numpy and numpy-f2py (1.6.1-2.fc17.i686) on my F16 machine and the problem went away.

Is some equivalent to this update going to make its way to F16 anytime soon? Vanilla F16 systems will still crash on this.

Comment 3 Gwyn Ciesla 2012-02-01 12:56:58 UTC
Sure, I'll simply push the changes from rahide to f16.

Comment 4 Fedora Update System 2012-02-01 13:32:26 UTC
numpy-1.6.1-2.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/numpy-1.6.1-2.fc16

Comment 5 Fedora Update System 2012-02-01 19:22:10 UTC
Package numpy-1.6.1-2.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing numpy-1.6.1-2.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-1104/numpy-1.6.1-2.fc16
then log in and leave karma (feedback).

Comment 6 Fedora Update System 2012-02-10 00:52:43 UTC
numpy-1.6.1-2.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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