Crash when deallocating HoughLines (OCV2.4.9)

asked 2014-09-21 15:29:49 -0600

Cross22
26 ●4

I am consistently seeing a crash after calling HoughLines or HoughLinesP. Oddly enough the crash is not happening inside those functions, but whenever the lines vector is being deallocated. (Moving the lines vector to global scope means the crash will happen later.) If I just push my own Vec4i items into the vector it works. If I do not call HoughLines/P it works too. But with HoughLines/P I get a crash / dbgheap error on Windows (using Visual Studio 2010/2013).

What might be causing this ?

// discard color
cvtColor(*pImg, *pImg, CV_RGBA2GRAY);
// turn into black/white with threshold
Rect bounds(100,100,400,400);
Mat center(*pImg, bounds);
threshold(center, center, 80, 255, THRESH_BINARY);
Canny(center, center, 50, 200, 3);
{
    std::vector<cv::Vec4i> lines;
    if (!pImg->empty()) {       
        const int MIN_LENGTH = 180;
        HoughLinesP(center, lines, 1, CV_PI / 180,
            80, MIN_LENGTH, 30);
    }
    // Still okay..
}
// This is where things go bad..

edit retag flag offensive close merge delete

Comments

do not use pointers to cv::Mat. you probably break it's internal refcounts.

i.e, the way you'doing it now, how should cvtColor allocate a different object for the grayscale Mat ? that's looks impossible given your pointers there)

berak ( 2014-09-22 00:50:08 -0600 )edit

Not sure what the concern is. Using the same Mat as input & output could be an issue, but why should dereferencing an object pointer be causing problems?

Cross22 ( 2014-09-24 23:15:14 -0600 )edit

again, please get rid of the pointers.

berak ( 2014-09-25 00:42:02 -0600 )edit

add a comment

answered 2014-09-21 19:49:19 -0600

rwong

1028 ●8 ●21

The following advice is meant for just starting the investigation. I may have missing some important points which may have caused the crash. But if you do solve the crash issue, please do share your findings so that all of us can learn from it.

(1)

Does the crash happen in debug build or release build? If you are using release build, try make a debug build and run it. A debug build may sometimes pinpoint the cause of corruption more precisely and earlier in time.

(2)

Can you make sure the size of *pImg is at least (500, 500) ?

(3)

Although cvtColor(src, dest) is capable of in-place operation according to some people, I wouldn't bet on it. _{(noted below)} Try call cvtColor with a new Mat dest; object as output --- which does not have to be initialized with size and type, as all it does is allocating a smart reference header. Keep in mind this is just for investigating why the crash occurs. It is not meant for general advice.

_{It takes moderately advanced C++ knowledge and code-reading into the OpenCV library to provide a technically accurate explanation of why it will/will not work. (I wouldn't try this at home.)}

(4)

Finally, make sure your own code and the OpenCV library are compiled with the same version of Microsoft Visual C++ compiler.

As noted in Breaking Changes in Visual C++ and Potential errors passing C/C++ objects across DLL boundaries, the object layouts of STL classes are subject to change as you upgrade the version of Visual C++.

(5)

As a side note, keep in mind that both HoughLines and HoughLinesP carry a remark saying that the image may be modified by the function. Also, the constructor syntax Mat(Mat, Rect), and see also this is for creating an ROI on the original image, which means the two Mat objects share the same memory region, and modifications to one Mat are visible through the other Mat. To eliminate this as a possible cause of error, try one of the two things:

Replace Mat center(*pImg, bounds); with Mat center = (*pImg)(bounds).clone();
Replace HoughLinesP(...); with center.setTo(cv::Scalar(0.0));

The above two code replacements are only used for investigating the cause of crash. They are not general advice. In other words, it is acceptable to allow the image to be modified by HoughLinesP through an ROI Mat, if this is exactly what you want.

edit flag offensive delete link

Comments

Thank you very much! I ended up recompiling the 2.4.9 source with VS2013 in various configurations, but the crash persists. Looking at the implementation I am very suspicious of the cvCvtSeqToArray() function which performs some pointer magic, treating my passed in std::vector<Vec4i> as a uchar*. I will try passing in a Mat as output instead.

Cross22 ( 2014-09-21 20:36:29 -0600 )edit

Thanks for your comment. Your suspicion might be correct - it requires non-trivial C++ code to be able to reallocate a std::vector as part of OutputArray operation. However, this usage (passing in an empty std::vector and have the function return a dynamically-resized number of results) is a standard practice in OpenCV (see the HoughLines tutorial), so if your suspicion turns out to be correct, this is a severe regression of OpenCV.

rwong ( 2014-09-21 21:04:24 -0600 )edit

There are a couple of questions on answers.opencv.org regarding DbgHeap assertions that look very similar. I do think that the OutputArray code makes some assumptions about the std::vector memory layout that are not true for Visual Studio's STL. The Debug lib asserts because the heap guards have been modified and the Release build just crashes. Since I want to get something going within the next 24h I ended up passing in a Mat instead of an std::vector and that is working fine.

Cross22 ( 2014-09-21 21:21:00 -0600 )edit

add a comment

Crash when deallocating HoughLines (OCV2.4.9)

Comments

1 answer

(1)

(2)

(3)

(4)

(5)

Comments

Links

Question Tools

Stats

Related questions

Crash when deallocating HoughLines (OCV2.4.9) edit

Comments

1 answer

(1)

(2)

(3)

(4)

(5)

Comments

Links

Question Tools

Stats

Related questions

Crash when deallocating HoughLines (OCV2.4.9)