OpenCV: Is cv::mat like a shared_ptr?

Question

i use opencv under windows with MSVC-2013. I get memory leaks. Now i try to figure out where they are.

I pulled out all stuff belonging to opencv and they disappeared. I grab them fram a camera, push them to a queue, work on them, push them to a video writer and the same object to the cui where it gets displayed for the user.

I use like most times local objects and thought that cv::Mat is like a std::shared_ptr<T>. I use often costructs like

void CChildView::OnPaint() 
{
    CPaintDC dc(this); // Gerätekontext zum Zeichnen

    // get the current image to convert it
    cv::Mat curr_img;
    {
        lock lk(m_monitor_gui);
        curr_img = m_gui_image.clone();
    }
    ....
}

My queue looks like:

cv::Mat     m_gui_image;
struct img_data
{
    time_point_t time;
    int nr;
    cv::Mat img;
};
std::deque<img_data>        m_grab_2_write;

    ............. grabber thread
// copy it to the writer queue
{
    lock lk(m_monitor_grab_write);

    // clone the raw frame
    cv::Mat to_other_thread;
    to_other_thread = raw_frame.clone();

    img_data tmp;
    tmp.nr = cnt++;
    tmp.img = to_other_thread;
    tmp.time = now;
    m_grab_2_write.push_back(tmp);
}

    ............. worker thread
// get all images from the queue
std::deque<img_data> all_images;
{
    lock lk(m_monitor_grab_write);
    all_images = m_grab_2_write;
    m_grab_2_write.clear();
}
    ......
// copy the current image to the display
{
    lock lk(m_monitor_gui);
    m_gui_image = current_frame.img;
}

Now i work with the local all_images queue to block the graber thread only for the minimal amount of time.

In the worker i pull them out of the local queue.

while (all_images.size())
{
    img_data current_frame = all_images.front();
    all_images.pop_front();
    .... do work with current_frame

This is a design i often used under Halcon and other libraries and had no leaks.... Where could be an issue?

The leak appears when just one cv::mat is allocated on the stack in the OnPaint() handler. I do absolutely nothing with it, just a local variable. I tried to reproduce it in a plain console application but it didn't show up.

I use opencv 2.4.9.

---

I pulled out everything regarding opencv and i check with depends that there is nothing opencv reagring loaded.

Then i add the following "PaintHandler" to my application:

void CChildView::OnPaint() 
{
    lock lk(m_monitor_gui);
    CPaintDC dc(this);
    // get the current image to convert it
    cv::Mat m;
}

Then it leaks. When i remove the local variable cv::Mat m it doesnt leak.

---

Detected memory leaks!
Dumping objects ->
{157} normal block at 0x005EDA48, 29 bytes long.
 Data: <    X ^ _ ^     > 00 00 00 00 58 DA 5E 00 5F DA 5E 00 00 00 00 00 
{156} normal block at 0x005ED9B8, 77 bytes long.
 Data: <      ^     (   > CD CD CD CD B8 D9 5E 00 00 00 00 00 28 00 00 00 
{155} normal block at 0x005ED930, 74 bytes long.
 Data: <            0 ^ > CD CD CD CD CD CD CD CD CD CD CD CD 30 D9 5E 00 
{154} normal block at 0x005ED8A8, 73 bytes long.
 Data: <      ^     (   > CD CD CD CD A8 D8 5E 00 00 00 00 00 28 00 00 00 
{153} normal block at 0x005ED818, 81 bytes long.
 Data: <      ^     (   > CD CD CD CD 18 D8 5E 00 00 00 00 00 28 00 00 00 
{152} normal block at 0x005ED790, 73 bytes long.
 Data: <              ^ > CD CD CD CD CD CD CD CD CD CD CD CD 90 D7 5E 00 
{151} normal block at 0x005ED700, 81 bytes long.
 Data: <              ^ > CD CD CD CD CD CD CD CD CD CD CD CD 00 D7 5E 00 
{150} normal block at 0x005ED208, 76 bytes long.
 Data: <      ^     (   > CD CD CD CD 08 D2 5E 00 00 00 00 00 28 00 00 00 
Object dump complete.

Leak result with one unused cv::Mat

Answer 1

cv::Mat is indeed like shared_ptr<> and should not be leaking properly allocated data.
For debugging try simplifying your code to be single threaded.

Your error might be related to multithreading issues, or maybe CRT mismatches. Are you linking with shared libs?

Static linking often solves these kinds of problems.

Answer 2

static linking did fix this. Now there is no memory leak.