Memory leak in OpenCV 4.80

Windows 10, Visual Studio 2022, OpenCV 4.80 compiled successfully with Visual Studio to static libs.

With this minimal example linked with the static libs I get memory leaks


#include <opencv2\opencv.hpp>

int main()
{
  _CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF); 
  cv::VideoCapture cap(0, cv::CAP_DSHOW); *// Also tried cv::CAP_MSMF, cv::CAP_ANY*
  cap.release();  
}

At program termination I get lots of these:

Detected memory leaks!
Dumping objects ->
{473} normal block at 0x0000022AF8B34460, 16 bytes long.
 Data: < wA             > F0 77 41 03 F7 7F 00 00 01 00 00 00 CD CD CD CD 
{260} normal block at 0x0000022AF8B29D00, 40 bytes long.
 Data: <P   *   P   *   > 50 9E B2 F8 2A 02 00 00 50 9E B2 F8 2A 02 00 00 
{259} normal block at 0x0000022AF8B29980, 40 bytes long.
 Data: <    *       *   > 90 9C B2 F8 2A 02 00 00 90 9C B2 F8 2A 02 00 00 
{258} normal block at 0x0000022AF8B33410, 16 bytes long.
 Data: <0!  *           > 30 21 B3 F8 2A 02 00 00 00 00 00 00 00 00 00 00

… etc …

don’t just run a tool. know its limitations. memory leak checkers regularly emit false positives on real-world code.

those aren’t real memory leaks. it may be false positives or unavoidable due to the complexity of all involved libraries (threading, OpenCL, …). at the very least, those look like constant initial waste, not growing.

if you can present a situation that leaks memory at an appreciable rate and can make it to a gigabyte or more of growth on top of the initial process memory, then you’ve got a case.

any MRE for a “leaks!” claim better contain an infinite loop. if it doesn’t and process memory still grows boundlessly, that would be exceedingly rare.

1 Like

Ok, I will find another computer to run the code on and check that the leaks are “normal”.