[SciPy-user] extracting elements of a matrix using arrays as indices (SEGFAULT!)

Stéfan van der Walt stefan@sun.ac...
Thu May 22 00:58:20 CDT 2008

2008/5/22 Travis E. Oliphant <oliphant@enthought.com>:
> Michael Hearne wrote:
>> Thanks for the help - the method below works just fine in my real
>> application (which has nothing to do with setting elements of an array
>> to zero - that was just a simple example of something to _do_ with the
>> data being indexed).
>> However, I am still concerned about the larger problem of getting a
>> segfault using ANY method of indexing an array.  If it is user error
>> that is causing the problem, then shouldn't I get an exception that
>> tells me my syntax is somehow incorrect?
>> I've added SEGFAULT to the subject line in hopes that someone
>> responsible for the core NumPy code (Travis O., perhaps?) will take
>> notice and address the issue.  If that happens, once again, I'm happy
>> to help test on my version of NumPy wherever needed.
>> Thanks for all the suggestions,
>> Mike
>> On May 21, 2008, at 8:10 AM, Alan McIntyre wrote:
>>> On Wed, May 21, 2008 at 9:51 AM, Michael Hearne <mhearne@usgs.gov
>>> <mailto:mhearne@usgs.gov>> wrote:
>>>> If I try that on a larger example, similar to the second one I made
>>>> yesterday:
>>>> nrows = 648
>>>> ncols = 690
>>>> data = rand(nrows,ncols)
>>>> i,j = (data < 0.14).nonzero()
>>>> data[i,:][:,j] = data[i,:][:,j]*0
> Just a suggestion, but you will get the attention of the NumPy
> developers more quickly on the numpy-discussion@scipy.org mailing list
> This kind of indexing is going to be very slow and it won't do what you
> want.
> A couple of points:
> data[i,:] will return a copy and then [:,j] will set values into that
> copy of the data (which is then not bound to anything so you lose it).
> I can't think of any example that I would use
> data[<something>][<something>] = <something>
> You are right that it should not segfault.   How much memory do you
> have?     My first guess is that you are running out of memory and there
> is some malloc that is not being checked correctly,   If you can run the
> code under gdb and give a backtrace when the error occurs it would be
> very helpful to trac it down.

This is where it happens:

#0  0x00509c8f in DOUBLE_copyswap (dst=0x6ccaa000, src=0x16d0058,
swap=0, arr=0x489460) at arraytypes.inc.src:993
#1  0x00568ce7 in array_subscript (self=<value temporarily
unavailable, due to optimizations>, op=<value temporarily unavailable,
due to optimizations>) at arrayobject.c:2556
#2  0x00569042 in array_subscript_nice (self=0x48a620, op=0x77aa8) at


More information about the SciPy-user mailing list