Created attachment 152018 [details] Code from the minimal example as a file. In code only using pointers to doubles and pointers to pointers to doubles, we see a memory leak related to 'operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so)'. Minimal example: ```C++ void divide2DDoubleArray(double * &block, double ** &subblockdividers, int noofsubblocks, int subblocksize){ /* The starting address of a block of doubles is used to generate * pointers to subblocks. * * block: memory containing the original block of data * subblockdividers: array of subblock addresses * noofsubblocks: specify the number of subblocks produced * subblocksize: specify the size of the subblocks produced * * Design by contract: application should make sure the memory * in block is allocated and initialized properly. */ // Build 2D matrix for cols subblockdividers=new double *[noofsubblocks]; subblockdividers[0]= block; for (int i=1; i<noofsubblocks; ++i) { subblockdividers[i] = &subblockdividers[i-1][subblocksize]; } } int main(){ double * testarray = new double[16]; double ** pTestarray; divide2DDoubleArray(testarray, pTestarray, 4, 4); delete[] pTestarray; } ``` Compiled with: ``` g++ -g valgrind_error.cpp -o ve.out ``` and ran with ``` valgrind --leak-check=yes ./ve.out ``` yields: ``` ==5775== Memcheck, a memory error detector ==5775== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==5775== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==5775== Command: ./ve.out ==5775== ==5775== ==5775== HEAP SUMMARY: ==5775== in use at exit: 128 bytes in 1 blocks ==5775== total heap usage: 3 allocs, 2 frees, 72,864 bytes allocated ==5775== ==5775== 128 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==5775== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==5775== by 0x109283: main (valgrind_error.cpp:25) ==5775== ==5775== LEAK SUMMARY: ==5775== definitely lost: 128 bytes in 1 blocks ==5775== indirectly lost: 0 bytes in 0 blocks ==5775== possibly lost: 0 bytes in 0 blocks ==5775== still reachable: 0 bytes in 0 blocks ==5775== suppressed: 0 bytes in 0 blocks ==5775== ==5775== For lists of detected and suppressed errors, rerun with: -s ==5775== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) ```
I also added this simple example to https://stackoverflow.com/questions/32995657/valgring-memory-leak-from-operator-newunsigned-long
Note: The memory leak in the minimal example can be removed by adding an extra delete[] testarray; In my original problem the array comes from outside from Python. (it is a numpy array coming in through a swig interface, ) The life time of the python array is under control of Python garbage collection. There I have the following valgrind outptu: ``` ==115608== 320 bytes in 4 blocks are definitely lost in loss record 6,737 of 8,021 ==115608== at 0x483C583: operator new[](unsigned long) (in /usr/lib/x86_64-linux-gnu/valgrind/vgpreload_memcheck-amd64-linux.so) ==115608== by 0x152A9AE8: patchExtractor::divide2DDoubleArray(double*&, double**&, int, int) (patchExtractor.cpp:468) ==115608== by 0x152AB073: patchExtractor::calcInternalHistograms(int, int, double*, int, int*, int, double*) (patchExtractor.cpp:1296) ==115608== by 0x152A4C65: patchExtractor_cpp_calcInternalHistograms (patchExtractor_wrap.cpp:3641) ==115608== by 0x152A4C65: _wrap_patchExtractor_cpp_calcInternalHistograms (patchExtractor_wrap.cpp:4739) ==115608== by 0x5F69C9: PyCFunction_Call (in /usr/bin/python3.8) ==115608== by 0x5F74F5: _PyObject_MakeTpCall (in /usr/bin/python3.8) ==115608== by 0x571163: _PyEval_EvalFrameDefault (in /usr/bin/python3.8) ==115608== by 0x5F6CD5: _PyFunction_Vectorcall (in /usr/bin/python3.8) ==115608== by 0x56BBF9: _PyEval_EvalFrameDefault (in /usr/bin/python3.8) ==115608== by 0x50BB2D: ??? (in /usr/bin/python3.8) ==115608== by 0x56BACC: _PyEval_EvalFrameDefault (in /usr/bin/python3.8) ==115608== by 0x5F6CD5: _PyFunction_Vectorcall (in /usr/bin/python3.8) ```
I'm not sure why you call this a memory leak in valgrind - it's valgrind reporting a memory leak in your program. It's also completely correct - you allocate two arrays but only free one. You allocate an array of double in main, which you assign to testarray, and that allocation is never freed. You also allocate an array of pointers to double in divide2DDoubleArray which you return to main via the subblockdividers reference parameter where is is storeed in pTestarray. You then free pTestarray, but that is an array of raw pointers so freeing it has no effect on the pointers it contains and they remain allocated, so the fact that the first one points to testarray does not mean testarray gets freed.
The testarray is not of the unsigned long type. It is of the type double. If the code I provided would complain about an operator new[](double) I would agree that we would be talking about the correct detection of an error. In the context of Swig it is under Python memory management and I get the same error. | You then free pTestarray, but that is an array of raw pointers so freeing it has no effect on the pointers it contains | and they remain allocated, so the fact that the first one points to testarray does not mean testarray gets freed. The memory the pointers in pTestArray point to are subsets of testarray and do not represent separately allocated blocks. delete [] testarray should suffice to free that memory, and it does. But than the problem doesn't show. I can therefore make it go away in a cpp context but not when the array comes in from Python.
You misunderstand - the "unsigned long" there is not the type of the array, it's the argument to operator new, which is just the number of bytes to allocate and is always unsigned long (well std::size_t but apparently that is equivalent to unsigned long on your platform). See https://en.cppreference.com/w/cpp/memory/new/operator_new which lists the various versions of operator new - in this case it is the second one that was called to do the allocation.
OK, that makes sense. I guess I need a minimal breaking example with Swig then.
Will you please stop reopening this bug. This is not a bug. There is no problem in valgrind disclosed here.
I am sorry for reopening the bug I am not using this interface a lot. I created a minimal swig example, but could not reproduce. And now I finally agree there is no bug. Problem can be traced down to an return statement when an error condition occurs. Freeing before returning solves the problem. I guess it reminds me why more then 1 return statement is bad programming practice. Thanks for your feedback Tom!