[Numpy-discussion] memory corruption bug

[Bill Baxter]

You're sure it's not just pass-by-reference semantics biting you?
If you make an array and pass it to another class or function, by default
they just get a reference to the same array.
so e.g.:

a = numpy.array([1,2,3])
some_class.set_array(a)
a[1] = 10

Then both the local 'a' and the 'a' that some_class has are now [1,10,3].
If you don't want that sharing then you need to make an explicit copy of a
by calling a.copy().
Watch out for lists or dicts of arrays too.   The python idom for copying a
list:  new_list = list_orig[:], won't copy the contents of elements that are
array.  If you want to be sure to make complete copies of complex data
structures, there's the deepcopy method of the copy module.  new_list =
copy.deepcopy(list_orig).

I found a bunch of these sorts of bugs in some code I ported over from
Matlab last week.  Matlab uses copy semantics for everything, so if you pass
a matrix A to a function in Matlab you can always treat it as a fresh local
copy inside the function.  Not so with Python.  I found that locating and
fixing those bugs was the most difficult thing about porting Matlab code to
Numpy (that and the lack of some major toolkit or function you use in Matlab
doesn't have an equivalent in Numpy... like eigs()).

--bb



On 8/26/06, Sven Schreiber <svetosch at gmx.net> wrote:
>
> Hi,
> I experienced this strange bug which caused a totally unrelated variable
> to be overwritten (no exception or error was raised, so it took me while
> to rule out any errors of my own).
>
> The context where this is in is a method of a class (Vecm.getSW()), and
> the instance of Vecm is created within a different class (GG.__init__).
> Now, the affected variable is in the namespace of GG (it's GG.urate),
> and so I would think that anything local in Vecm.getSW() should not
> affect GG.urate, right?
>
> Originally I did:
>
> glx[lag:, :] -= temp
>
> But that caused the described problem. Then I tried:
>
> glx[lag:, :] = glx[lag:, :] - temp
>
> But the same problem remains. Then I worked around the slice assignment
> like this:
>
> temp4 = r_[zeros([lag, n_y]), temp]
> glx = glx - temp4
>
> And everything is ok! However, when I alter the second line of this
> workaround to:
>
> glx -= temp4
>
> The problem reappears! So I'm not even sure whether this is one or two
> bugs...
>
> This is with yesterday's numpy svn on windows, but the same thing
> happens with an earlier svn (~b2) as well. If you need further info,
> please tell me how to provide it.
>
> Thanks,
> Sven
>
>
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060826/ac38618d/attachment.html>