-
-
Notifications
You must be signed in to change notification settings - Fork 10.9k
cumsum of mutable objects in an array gives wrong results #7402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
It works for me: >>> np.cumsum(arr, out=arr)
array([[1], [1, 1], [1, 1, 1], [1, 1, 1, 1]], dtype=object) What version of numpy and python and on what system are you using? |
I have tried on: Tomorrow I will try at work, on a Linux machine. |
Can reproduce on python 2.7 at least with both 1.8 and master. It segfaults during the list concat. Best guess is that the refcount drops to zero and one of the list got cleaned up. Though I am not sure why that should happen. Might want to check python as well for some weirdness. Valgrind trace:
|
I have checked on Linux Mint, Python 2.7.6, numpy 1.8.2. The same happens. I have also checked with |
OK, found the bug, see gh-7407, simple decref before incref for the first element. |
BUG: Fix decref before incref for in-place accumulate
While trying to replace Python
long
integers with gmpy2mpz
objects in anobject
array, I discovered a rather strange behavior of the in-placenp.cumsum
function (without=
). It seems that the objects are reused in some way. E.g.prints
[mpz(2) mpz(2) mpz(3) mpz(4)]
.With the second
cumsum
uncommented, the values are7, 7, 7, 11
. There is no problem iflong
is used instead ofmpz
.It seems that a similar issue can be reproduced using tuples and lists in an array.
As I would expect, the first print shows an array of tuples of growing length. However, the second print causes
Segmentation fault: 11
.The text was updated successfully, but these errors were encountered: