10000 Various Valgrind errors (Trac #110) · Issue #708 · numpy/numpy · GitHub
[go: up one dir, main page]

Skip to content

Various Valgrind errors (Trac #110) #708

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

Closed
numpy-gitbot opened this issue Oct 19, 2012 · 4 comments
Closed

Various Valgrind errors (Trac #110) #708

numpy-gitbot opened this issue Oct 19, 2012 · 4 comments

Comments

@numpy-gitbot
Copy link

Original ticket http://projects.scipy.org/numpy/ticket/110 on 2006-05-11 by @alberts, assigned to unknown.

When running the file to be attached, Valgrind shows up errors in 2 different contexts. I tried reducing the test to a few lines, but removing much more code causes one of the bugs to disappear. One of the errors seems to be the same one as in ticket #551.

The code basically calculates the top triangle of a symmetric matrix, including the diagonal, with some use of record arrays.

Valgrind errors (used Valgrind 3.1.1):

==5803== 408 bytes in 2 blocks are possibly lost in loss record 21 of 38
==5803==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==5803==    by 0x1BEBCD1D: PyArray_NewFromDescr (arrayobject.c:4444)
==5803==    by 0x1BF1B322: construct_loop (ufuncobject.c:1017)
==5803==    by 0x1BF1BB80: PyUFunc_GenericFunction (ufuncobject.c:1419)
==5803==    by 0x1BF1CD1F: ufunc_generic_call (ufuncobject.c:2670)
==5803==    by 0x1B9383B3: PyObject_Call (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1B93847B: PyObject_CallFunction (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1BEAEC12: PyArray_GenericBinaryFunction (arrayobject.c:2771)
==5803==    by 0x1B936299: (within /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1B936CFF: PyNumber_Multiply (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1BEDC620: PyArray_Round (multiarraymodule.c:268)
==5803==    by 0x1BEDCA49: array_round (arraymethods.c:1490)
==5803==    by 0x1B95E1CA: PyCFunction_Call (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1B997091: PyEval_EvalFrame (in /usr/lib/libpython2.4.so.1.0)
...





==5803== 530672 (6520 direct, 524152 indirect) bytes in 163 blocks are definitely lost in loss record 32 of 38
==5803==    at 0x1B909222: malloc (vg_replace_malloc.c:130)
==5803==    by 0x1BEB0C5F: array_alloc (arrayobject.c:5582)
==5803==    by 0x1BEBCADB: PyArray_NewFromDescr (arrayobject.c:4393)
==5803==    by 0x1BF1B322: construct_loop (ufuncobject.c:1017)
==5803==    by 0x1BF1BB80: PyUFunc_GenericFunction (ufuncobject.c:1419)
==5803==    by 0x1BF1CD1F: ufunc_generic_call (ufuncobject.c:2670)
==5803==    by 0x1B9383B3: PyObject_Call (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1B93847B: PyObject_CallFunction (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1BEAEC12: PyArray_GenericBinaryFunction (arrayobject.c:2771)
==5803==    by 0x1B936299: (within /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1B936CFF: PyNumber_Multiply (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1BEDC620: PyArray_Round (multiarraymodule.c:268)
==5803==    by 0x1BEDCA49: array_round (arraymethods.c:1490)
==5803==    by 0x1B95E1CA: PyCFunction_Call (in /usr/lib/libpython2.4.so.1.0)
==5803==    by 0x1B997091: PyEval_EvalFrame (in /usr/lib/libpython2.4.so.1.0)
...
@numpy-gitbot
Copy link
Author

Attachment added by @alberts on 2006-05-11: numpybug.py

@numpy-gitbot
Copy link
Author

@teoliphant wrote on 2006-05-17

We need a more clear test to see if there really is any problem or if your code is just hanging on to references. I can't see any errors in the code that could cause this, and there is just too much code to narrow done what is causing Valgrind to complain.

@numpy-gitbot
Copy link
Author

Milestone changed to Unscheduled by @teoliphant on 2006-05-17

@numpy-gitbot
Copy link
Author

@teoliphant wrote on 2006-05-17

Just noticed that the errors were coming from Round. Looked in that code and noticed two PyObject arrays were not being DECREF'd (the return object wasn't even being stored). I think this may fix the problem.

Fixed in r2519

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant
0