memory leak in tensor wrappers... ?
spateux opened this issue · 3 comments
I found that the tensor_wrappers functions seems to introduce some memory leaks.
To show that behavior I provide a simple program that reports memory usage and show memory leaks using some type of calling convention (i.e. without specifying destination image result).
I observed that when we do not provide a "dst" image to a wrapped openCV function, then memory leaks occur.
Furthermore when "dst" image is provided then memory leaks seem to disappear (launch provided sample program with --noleak option).
This sounds like a problem in cv.unwrap_tensors function... but that could also be somewhere else?
A possible guess could be in the "stride" and "size" fields of the THByteTensor that are allocated in the C.transfer_tensor function (since I do not see deallocating function, nor "garbage collected" allocation). But I may be wrong...
An additional comment is that many functions wrapping need to be corrected since the assertion on dest size does not work (since dstSize has been converted by operator cv.Size) -- see provided sample code where the assertion is commented to prevent error at execution
The sample attached program shows that behavior on a simple function (pyrDown), but many other functions should be concerned.
Kind regards.
Thank you so much for looking into this.
I've been keeping this in mind since #167 was published, did a couple of debugging sessions but still don't know the reason. Sorry for being so slow, it's because now this lib is just my side project so I have little time to work on it.
Looks like this really needs attention. Putting it into my calendar. I plan to focus on this next Tuesday.
For now I only know that the bug can be reproduced really quickly if the image is tiny (I've reproduces this behaviour with your code as well). So your guess should be right -- it has something to do with some small blocks like stride and size. I checked them in December and found no bugs, need to recheck...
As for argument checking and assertions, they are quite redundant, I've dropped them roughly after imgproc package because there's too much manual work in it and, moreover, users can easily check this stuff themselves with the documentation.
Stay tuned!
Cleared it. I didn't notice that while Mat is deallocated properly, it refers to a separately allocated UMat object, which leaks.
Woohoo!
Merci beaucoup for your participation!