Bug 770857

Summary: Type-converting ufunc calls corrupt memory, leading to segfaults
Product: [Fedora] Fedora Reporter: Peter Williams <peter>
Component: numpyAssignee: Gwyn Ciesla <gwync>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 16CC: gwync, jspaleta, orion, rdieter, sochotni, tomspur
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: numpy-1.6.1-2.fc16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-02-10 00:52:43 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Test case demonstrating the bug none

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.