8000 Reference leaks (Trac #562) · Issue #1160 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Reference leaks (Trac #562) #1160

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.

Sign up for GitHub

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

Jump to bottom
Closed
numpy-gitbot opened this issue Oct 19, 2012 · 13 comments
Closed

Reference leaks (Trac #562) #1160

numpy-gitbot opened this issue Oct 19, 2012 · 13 comments
Labels
00 - Bug component: numpy._core
Milestone
1.1.0

Comments

@numpy-gitbot
Copy link

Original ticket http://projects.scipy.org/numpy/ticket/562 on 2007-08-03 by @alberts, assigned to unknown.

Lisandro Dalcin reported some possible reference leaks:

http://projects.scipy.org/pipermail/numpy-discussion/2007-August/028749.html
http://projects.scipy.org/pipermail/numpy-discussion/2007-August/028757.html
@numpy-gitbot
Copy link
Author

trac user langner wrote on 2007-10-28

Another memory leaks has been found, although possibly not the same:
http://projects.scipy.org/pipermail/numpy-discussion/2007-October/029667.html
http://projects.scipy.org/pipermail/numpy-discussion/2007-October/029669.html

@numpy-gitbot
Copy link
Author

trac user langner wrote on 2007-10-28

This is something different, so I opened a separate ticket (#1200).

@numpy-gitbot
Copy link
Author

trac user matthieu.brucher wrote on 2008-03-19

Running the debug python, I noticed that :

def npy_asarray_2():
    a = numpy.zeros(5, dtype=float)
    b = numpy.array(a, dtype=float)
    del a, b

leaks references as well, so it may not be related to copies at all.

@numpy-gitbot
Copy link
Author

Attachment added by trac user matthieu.brucher on 2008-03-19: patch-562

@numpy-gitbot
Copy link
Author

trac user matthieu.brucher wrote on 2008-03-19

I've attached a patch that does not induce regressions.
l5655 : the PyArray_DESCR() call increments the description count, but this count is never decreased, so the patch :

  • decrease the reference count in the first path
  • does nothing (the reference count should be incremented, but as it was already incremented, nothing is done) compared to an increased in the past

@numpy-gitbot
Copy link
Author

trac user matthieu.brucher wrote on 2008-03-19

A code to test for the presence of the leak with valgrind (from Lisandro message) :

def npy_asarray():
    a = numpy.zeros(5, dtype=float)
    b = numpy.asarray(a, dtype=float)
    del a, b

@numpy-gitbot
Copy link
Author

@stefanv wrote on 2008-03-20

Added as r4897. Thank you for tracking this down!

@numpy-gitbot
Copy link
Author

@teoliphant wrote on 2008-03-21

I don't understand this patch. I don't think it is correct. The PyArray_DESCR() "call" does not increment the reference count. It is just a macro to access the array descriptor object in an ndarray.

@numpy-gitbot
Copy link
Author

@pv wrote on 2008-03-21

r4897 apparently causes a segfault / reference count error in numpy.test(), see #1308

@numpy-gitbot
Copy link
Author

trac user matthieu.brucher wrote on 2008-03-21

Perhaps I missed something as there seems to be some worries about what I've done (#1308), but at least the reference leak error is (I'm 99% sure of that fact by having printed the reference counts of the different objects in this function, but I was wrong once, I could be twice ;)) in the _array_fromobject() function.

So perhaps that Travis and/or Paulin should take a look at it to correctly track what is going on.

BTW, with the latest SVN, python segfaults with Lisandro's test, which was not the case when I updated the patch.

I've added a display of the reference count of oldtype before line 5658 (Py_INCREF(op)) :

before : b7c938c0(22)
before: 146258, after: 146260, diff: [2]
before : b7c938c0(23)
before: 146262, after: 146263, diff: [1]
before : b7c938c0(24)
before: 146263, after: 146264, diff: [1]
before : b7c938c0(25)
before: 146264, after: 146265, diff: [1]
before : b7c938c0(26)
before: 146265, after: 146266, diff: [1]

It is clear that the reference count IS increasing.

BTW, the patch that was applied is not the one I supplied :|

@numpy-gitbot
Copy link
Author

@stefanv wrote on 2008-03-21

Sorry, I applied the wrong patch. Reverted in r4905. Has anyone had a chance to take a further look?

@numpy-gitbot
Copy link
Author

trac user matthieu.brucher wrote on 2008-03-21

Thank you stéfan ;)

The reference count I showed are made from the multiarray.c file without the faulty patch (adress of the PyObject and its refcnt), so it is what was going on before my fix which is not correct, but which does the job, so the issue is perhaps more convoluted than I thought).

@numpy-gitbot
Copy link
Author

@teoliphant wrote on 2008-03-22

I've looked over this and finally read what Lisandro reported. He was right in that use of DescrConverter in PyArg_ParseTuple needs to be tracked carefully to be sure and get reference counts correct.

I've done this and applied the fix in r4911. Running his original npyleaktest script with a debug build of Python showed no leaks in npy_asarray_2() so I'm closing this ticket.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
00 - Bug component: numpy._core
Projects
None yet
Milestone
1.1.0
Development

No branches or pull requests
1 participant
@numpy-gitbot
0