How to avoid false mem. leaks reported from cv::resize


I know this was briefly discussed in other topics, such as : [3509](

These TLS false leaks are a known issue and so far we were able to avoid having these reported by the automated tests by adding a “init” function before the tests run (and disable the leak checker) : this will allow the relevant functions to perform their allocations (it works for cv::cvtcolor, GaussianBlur, etc). However, for cv::resize this workaround is not that efficient, altough the dimensions of input/output are exactly the same as the ones in the production code. I sometimes see “leaks” reported. They come in multiples of 352 (no idea why) and from what I can tell the ratio of input/output sizes plays a role.

I use OpenCV 3.4.2, built from sources and statically linked. I tried with other versions as well (3.4.9, 4.2.0) and the behavior is the same. The mem. leak tool is not the smartest one (crtdbg), so adding a suppression list is not an option.

Do you have any suggestion on how this can be avoided ? The init. function and the tests are running on the same thread; there are no internal threads inside the SUT.

Thank you,

To make things even more strange, assume we have a google test suite with a simple MemLeak tool as test listener. Then the following “test” will fail with a “leak”. However, trying to resize to 256 it’s ok…