[C++]openCV Memory Leak

n0stradamus · 2010-11-20 15:45:10

Hi!

In a project of mine I need to capture a frame from my webcam every few seconds.
I thought openCV was fit to do the capturing, but I've run into some strange problem:

This code sample produces heavy memory leaks:

    // cap = cvCaptureFromCAM(0);

    while(true)
    {
        cap = cvCaptureFromCAM(0);
        img = cvQueryFrame( cap );
        cvReleaseCapture( &cap );
    }

    // cvReleaseCapture( &cap );

While this does not(or perhaps smaller^^):

    cap = cvCaptureFromCAM(0);

    while(true)
    {
        // cap = cvCaptureFromCAM(0);
        img = cvQueryFrame( cap );
        // cvReleaseCapture( &cap );
    }

    cvReleaseCapture( &cap );

I need to use the first method, because my frames need to be current, meaning where the webcam is at the moment. The first version provides this actuality, while the latter does not...
Does anyone know a nifty hack to solve this problem? It needn't be some openCV-Function, just something that gives me the possibility to grab a frame and store it somewhere on my harddrive

Edit: It ist NOT the cvReleaseImage(IplImage* img) function I forgot to use - tried that out

Last edited by n0stradamus (2010-11-20 15:46:20)

ngoonee · 2010-11-20 16:20:42

What's the datatype for cap? If its a pointer, make sure to delete it. I use opencv a bit, basically for its cv::Mat class, but I use pointers everywhere, so when I forget to delete one it memory leaks. Perhaps that's your issue?

n0stradamus · 2010-11-20 16:40:47

Hey

cap is a CvCapture-Pointer and img an IplImage-Pointer.
By deleting, do you mean using 'delete' ? I tried that before, but it's no use either. The openCV-documentation says to use cvReleaseCapture(), which I do.
I just tested it on my laptop with another camera and had the same problem, so the probability it's a driver problem is quite small...
Do you happen to know another way to capture and store an image from a webcam?

Last edited by n0stradamus (2010-11-20 16:42:09)

ngoonee · 2010-11-21 10:12:15

n0stradamus wrote:

Hey
cap is a CvCapture-Pointer and img an IplImage-Pointer.
By deleting, do you mean using 'delete' ? I tried that before, but it's no use either. The openCV-documentation says to use cvReleaseCapture(), which I do.
I just tested it on my laptop with another camera and had the same problem, so the probability it's a driver problem is quite small...
Do you happen to know another way to capture and store an image from a webcam?

In my experience, the 'release' functions don't do proper work with pointers. Please show how you're declaring cap and img.

n0stradamus · 2010-11-21 10:49:58

There you go, the whole main():

// openCV
#include <opencv/cv.h>
#include <opencv/highgui.h>

// std
#include <iostream>


int main(int argc, char *argv[])
{
    IplImage *img=0;
    CvCapture *cap=0;
    //cap = cvCaptureFromCAM(0);

    while(true)
    {
        cap = cvCaptureFromCAM(0);
        img = cvQueryFrame( cap ); /*<- comment out to see that cvReleaseCapture() leaks*/
        cvReleaseCapture( &cap );
    }
    return 0;
}

I can confirm that the cvReleaseCapture()-Function doesn't do its job properly. Having commented out the cvQueryFrame()-Part, recompiled and run, the memory leaks were considerably smaller. What did you do to counter the malfunctioning 'release'-functions ?

falconindy · 2010-11-21 15:15:55

You're passing the address of cap (already a pointer) to the release function. Does cvReleaseCapture accept a cvCapture** or cvCapture* ?

edit: really should just look at the API myself.

Last edited by falconindy (2010-11-21 17:03:10)

ngoonee · 2010-11-21 16:25:33

I'd look at the documentation for cvCaptureFromCAM to see what sort of auto-allocation it does. I still believe you need to delete cap itself (rather than just the object pointed to), as that's how it works for cv::Mat objects.

n0stradamus · 2010-11-21 18:07:57

ngoonee wrote:

I'd look at the documentation for cvCaptureFromCAM to see what sort of auto-allocation it does. I still believe you need to delete cap itself (rather than just the object pointed to), as that's how it works for cv::Mat objects.

Tried and didn't work -.-
I've just been browsing through the openCV-Documentation and discovered the VideoCapture-Class and the Mat-Class mentioned by you.
As I'm only using openCV to capture a picture from my wicked webcam and nothing else, I wasn't aware of the of the fact that IplImage was somewhat deprecated. Sorry, I didn't know

But the leak still persists with these Two:

    while(true)
    {
        cv::VideoCapture cap(0);
        if(!cap.isOpened())
            return -1;

        cap >> img;
    }

EDIT: I solved the problem for now by using a dirty hack: I put the Image-Capture-And-Save-Routine into a seperate program which I always start when needed. Thus I avoid the huge memory leaks and am still able to provide image actuality. Would be nice to know, why this stuff leaks, though^^

Last edited by n0stradamus (2010-11-21 18:10:29)

ngoonee · 2010-11-21 23:32:50

n0stradamus wrote:

    while(true)
    {
        cv::VideoCapture cap(0);
        if(!cap.isOpened())
            return -1;

        cap >> img;
    }
EDIT: I solved the problem for now by using a dirty hack: I put the Image-Capture-And-Save-Routine into a seperate program which I always start when needed. Thus I avoid the huge memory leaks and am still able to provide image actuality. Would be nice to know, why this stuff leaks, though^^

I'll raise my hand and admit I haven't read the link you link to. However, the way you're doing it above there is sure to leak, you need to somehow release/clear cap (and probably img as well) at the end of the loop. Try and if which checks whether they have values.

riooo · 2011-07-21 06:14:25

I have on Arch some problems with OpenCV too. Here is a simple code:

#include "opencv2/opencv.hpp"

using namespace cv;

int main(int argc, char* argv[]) {

    Mat image;

    image.release();
  return 0;
}

When I compile thic code, I get some errors in valgrind.

[riooo@myhost OpenCV]$ valgrind ./opencv
==2642== Memcheck, a memory error detector
==2642== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==2642== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==2642== Command: ./opencv
==2642== 
==2642== Source and destination overlap in memcpy(0x1435ab3b, 0x1435ab3a, 2)
==2642==    at 0x4C27B46: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2642==    by 0x74B89C4: ??? (in /lib/libc-2.14.so)
==2642==    by 0x74B8386: readdir (in /lib/libc-2.14.so)
==2642==    by 0xB7BCF9F: ??? (in /usr/lib/libdc1394.so.22.1.5)
==2642==    by 0xB7AD44F: dc1394_new (in /usr/lib/libdc1394.so.22.1.5)
==2642==    by 0x56A5468: CvDC1394::CvDC1394() (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642==    by 0x5692145: ??? (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642==    by 0x56B8935: ??? (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642==    by 0x568F61A: ??? (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642== 
==2642== Source and destination overlap in memcpy(0x14362dbb, 0x14362dba, 2)
==2642==    at 0x4C27B46: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2642==    by 0x74B89C4: ??? (in /lib/libc-2.14.so)
==2642==    by 0x74B8386: readdir (in /lib/libc-2.14.so)
==2642==    by 0x1234ABFC: ??? (in /usr/lib/libusb-1.0.so.0.0.0)
==2642==    by 0x1234B767: ??? (in /usr/lib/libusb-1.0.so.0.0.0)
==2642==    by 0x12345E04: libusb_init (in /usr/lib/libusb-1.0.so.0.0.0)
==2642==    by 0xB7BE5FD: ??? (in /usr/lib/libdc1394.so.22.1.5)
==2642==    by 0xB7AD44F: dc1394_new (in /usr/lib/libdc1394.so.22.1.5)
==2642==    by 0x56A5468: CvDC1394::CvDC1394() (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642==    by 0x5692145: ??? (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642==    by 0x56B8935: ??? (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642==    by 0x568F61A: ??? (in /usr/lib/libopencv_highgui.so.2.3.0)
==2642== 
==2642== 
==2642== HEAP SUMMARY:
==2642==     in use at exit: 8,288 bytes in 4 blocks
==2642==   total heap usage: 128 allocs, 124 frees, 93,263 bytes allocated
==2642== 
==2642== LEAK SUMMARY:
==2642==    definitely lost: 0 bytes in 0 blocks
==2642==    indirectly lost: 0 bytes in 0 blocks
==2642==      possibly lost: 0 bytes in 0 blocks
==2642==    still reachable: 8,288 bytes in 4 blocks
==2642==         suppressed: 0 bytes in 0 blocks
==2642== Rerun with --leak-check=full to see details of leaked memory
==2642== 
==2642== For counts of detected and suppressed errors, rerun with: -v
==2642== ERROR SUMMARY: 278 errors from 2 contexts (suppressed: 7 from 7)

On FreeBSD with the same version of valgrind and OpenCV, it works fine without errors. Is here somebody, who knows, where is the problem?? Thanks for your time.

sebcactus · 2011-07-24 19:13:32

Are you on i686 or x86_64?

I am running i686 and don't have the problem.

Also note that you don't need to release the image, the destructor should do it.

riooo · 2011-07-25 16:35:02

I am running on x86_64 but I tested this code on other Linux x86_64 and on FreeBSD and it works fine. I realy don't know, where the problem is.

tavianator · 2011-07-25 20:27:45

riooo wrote:

I have on Arch some problems with OpenCV too. Here is a simple code: ...
[riooo@myhost OpenCV]$ valgrind ./opencv
...
==2642== Source and destination overlap in memcpy(0x1435ab3b, 0x1435ab3a, 2)
...

The memcpy() warning is caused by a valgrind bug: https://bbs.archlinux.org/viewtopic.php … 73#p965373

Arch Linux

#1 2010-11-20 15:45:10

[C++]openCV Memory Leak

#2 2010-11-20 16:20:42

Re: [C++]openCV Memory Leak

#3 2010-11-20 16:40:47

Re: [C++]openCV Memory Leak

#4 2010-11-21 10:12:15

Re: [C++]openCV Memory Leak

#5 2010-11-21 10:49:58

Re: [C++]openCV Memory Leak

#6 2010-11-21 15:15:55

Re: [C++]openCV Memory Leak

#7 2010-11-21 16:25:33

Re: [C++]openCV Memory Leak

#8 2010-11-21 18:07:57

Re: [C++]openCV Memory Leak

#9 2010-11-21 23:32:50

Re: [C++]openCV Memory Leak

#10 2011-07-21 06:14:25

Re: [C++]openCV Memory Leak

#11 2011-07-24 19:13:32

Re: [C++]openCV Memory Leak

#12 2011-07-25 16:35:02

Re: [C++]openCV Memory Leak

#13 2011-07-25 20:27:45

Re: [C++]openCV Memory Leak

Board footer