Executive summary for ticket #619: Matrix_integer_dense__zero_out_matrix does not leak.
But there must be operations on dense matricies that do not properly deallocate elements that were allocated in Matrix_integer_dense__zero_out_matrix, so vagrind claims rightfully that those entries are leaked. Another interesting tidbit: A=matrix(ZZ,1000,1000,0) B=A.copy() leads to: ==31604== 8,000,000 bytes in 1,000,000 blocks are still reachable in loss record 1,975 of 1,979 ==31604== at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604== by 0x95A4C17: __gmpz_init (in /tmp/Work2/sage-2.8.3.6- clean/local/lib/libgmp.so.3.4.1) ==31604== by 0x205E840F: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense__zero_out_matrix (matrix_integer_dense.c:4 649) ==31604== by 0x206161E4: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___init__ (matrix_integer_dense.c:3769) ==31604== by 0x45A321: type_call (typeobject.c:436) ==31604== by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== by 0x480783: PyEval_EvalFrameEx (ceval.c:3775) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== by 0x4CFF37: function_call (funcobject.c:517) ==31604== by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== ==31604== ==31604== 8,000,000 bytes in 1,000,000 blocks are still reachable in loss record 1,976 of 1,979 ==31604== at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604== by 0x95A5BE0: __gmpz_init_set (in /tmp/Work2/sage-2.8.3.6- clean/local/lib/libgmp.so.3.4.1) ==31604== by 0x20605951: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___copy__ (matrix_integer_dense.c:3223) ==31604== by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== by 0x47DB71: PyEval_CallObjectWithKeywords (ceval.c:3433) ==31604== by 0x1E12C45C: __pyx_f_7matrix0_6Matrix_copy (matrix0.c: 845) ==31604== by 0x485B9B: PyEval_EvalFrameEx (ceval.c:3548) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== by 0x485BDF: PyEval_EvalFrameEx (ceval.c:494) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== ==31604== 16,000,000 bytes in 1 blocks are still reachable in loss record 1,977 of 1,979 ==31604== at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604== by 0x205E9766: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___new__ (matrix_integer_dense.c:2966) ==31604== by 0x205E9BE0: __pyx_tp_new_20matrix_integer_dense_Matrix_integer_dense (matrix_integer_dense.c:17692) ==31604== by 0x45A90A: tp_new_wrapper (typeobject.c:4022) ==31604== by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== by 0x47DB71: PyEval_CallObjectWithKeywords (ceval.c:3433) ==31604== by 0x20605868: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___copy__ (matrix_integer_dense.c:3189) ==31604== by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== by 0x47DB71: PyEval_CallObjectWithKeywords (ceval.c:3433) ==31604== by 0x1E12C45C: __pyx_f_7matrix0_6Matrix_copy (matrix0.c: 845) ==31604== by 0x485B9B: PyEval_EvalFrameEx (ceval.c:3548) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== ==31604== ==31604== 16,000,000 bytes in 1 blocks are still reachable in loss record 1,978 of 1,979 ==31604== at 0x4A05A66: malloc (vg_replace_malloc.c:207) ==31604== by 0x205E9766: __pyx_f_20matrix_integer_dense_20Matrix_integer_dense___new__ (matrix_integer_dense.c:2966) ==31604== by 0x205E9BE0: __pyx_tp_new_20matrix_integer_dense_Matrix_integer_dense (matrix_integer_dense.c:17692) ==31604== by 0x45A272: type_call (typeobject.c:422) ==31604== by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== by 0x480783: PyEval_EvalFrameEx (ceval.c:3775) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== by 0x4845B3: PyEval_EvalFrameEx (ceval.c:3660) ==31604== by 0x4865EF: PyEval_EvalCodeEx (ceval.c:2831) ==31604== by 0x4CFF37: function_call (funcobject.c:517) ==31604== by 0x4156A2: PyObject_Call (abstract.c:1860) ==31604== by 0x41BE0C: instancemethod_call (classobject.c:2497) But with A=matrix(ZZ,1000,1000,0) B=A.copy() del A del B the above problem is gone, no more "still reachable" that are caused to A or B. A.echelonize() doesn't leak for that A over ZZ either. burcin found out that "A = random_matrix(ZZ, 100, 120);" leaks, as does "A._pari_()" I am currently looking into getting useful information out of the Python garbage collector. So stay tuned. Cheers, Michael --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://sage.scipy.org/sage/ and http://modular.math.washington.edu/sage/ -~----------~----~----~----~------~----~------~--~---
