OpenCV:cv :: mat是否像shared_ptr一样?

时间:2015-05-13 13:47:06

标签: c++ opencv

我使用Windows下的opencv和MSVC-2013。我得到了内存泄漏。现在我试着找出它们的位置。

我拿出了所有属于opencv的东西,然后就消失了。我抓住他们的相机,将它们推到队列中,对它们进行操作,将它们推送到视频编写器,将相同的对象推送到cui,以便为用户显示。

我大多数时候都使用本地对象,并认为cv::Mat就像std::shared_ptr<T>。我经常使用像

这样的结构
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();
    }
    ....
}

我的队列如下:

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;
}

现在我使用本地all_images队列来阻止graber线程只有最短的时间。

在工作人员中,我将它们拉出本地队列。

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

这是我经常在Halcon和其他图书馆使用的设计,并且没有泄漏....哪里可能是个问题?

OnPaint()处理程序中的堆栈上只分配了一个cv :: mat时,就会出现泄漏。我对它一无所知,只是一个局部变量。我尝试在普通的控制台应用程序中重现它,但它没有显示出来。

我使用opencv 2.4.9。

我拿出了关于opencv的一切,我检查了取决于没有任何opencv reagring加载。

然后我将以下“PaintHandler”添加到我的应用程序中:

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

然后它泄漏了。当我删除局部变量cv::Mat m时,它不会泄漏。

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.

一个未使用cv::Mat

的泄漏结果

2 个答案:

答案 0 :(得分:2)

cv::Mat确实与shared_ptr<>类似,不应泄漏正确分配的数据 对于调试,请尝试将代码简化为单线程。

您的错误可能与多线程问题或CRT不匹配有关。你是否与共享库链接?

静态链接通常可以解决这些问题。

答案 1 :(得分:0)

静态链接确实解决了这个问题。现在没有内存泄漏。