C++ Compilation introduce errors - c++

Question

I have a multi-threaded C++ windows project in Visual Studio 2010 which uses Qt (5.1.1) and OpenCV (2.4.8). When I build it in Debug mode everything runs fine, but when I build it in Release mode the program crashes. Both configurations are almost identical (just in Release I have Multi-threaded DLL /MD and in Debug Multi-threaded Debug DLL /MDd), I disabled optimizations for the Release, and even enabled debug to catch the error. What's most weird is that the same piece of code that crashes, runs just fine in another console project.
The error is internal to OpenCV's code, it's not related to my code, my code is just:
void MyProject::findEllipses(QImage &frame, vector<RotatedRect> &ellipses)
{
Mat image = Mat(frame.height(), frame.width(), CV_8UC4, frame.scanLine(0));
cvtColor(image, image, CV_RGB2GRAY);
GaussianBlur(image, image, Size(3, 3), 0, 0, 4);
threshold(image, image, treshVal, 255, THRESH_BINARY);
vector<vector<Point> > contours;
Mat contoursImage = image.clone();
findContours(contoursImage, contours, CV_RETR_LIST, CV_CHAIN_APPROX_NONE, Point(0, 0));
// ....Mode Code
As I said in Debug the code runs without a problem, findContours calls _contours.create(total, 1, 0, -1, true); (in line 1720 of OpenCV's contours.cpp) and moves on that method....BUT in Release, when I step into _contours.create(total, 1, 0, -1, true), instead of executing that method, the program jumps to void _OutputArray::clear() const (line 1674 of matrix.cpp) and get's trapped in there, because it calls int k = kind(); in it's first line, which, instead of calling cv::kind(), calls:
int _InputArray::type(int i) const
{
int k = kind();
Which calls againg kind() which again calls type() (instead of kind()as it should), making an infinite recursive loop, bringing a stack overflow.
I tried to make a new Visual Studio 2010 project to see if this is a project creation problem but the problem persisted.
My guess is that the function adresses are wrong in release mode so when it tries to call create(), it instead calls another address, making a mess in the stack, but that's just my guess. At first I will blame OpenCV release dlls, but, as I said, in another console project that only runs that particular code, the code runs fine in bot build modes. I don't see how my other threads and code can trigger this behavior, since the error goes down to a wrong function call in OpenCV.
This is way beyond my knowledge and I have no idea how to fix this, I appreciate all the help I can get on this problem, because I already exausted all my ideas to fix it....
EDIT :
I made a small project so anyone can see what's happening.
The files are in:
https://app.box.com/s/3owljl44emv57erinrf8
In order to run it, you have to have OpenCV 2.4.8 and Qt 5.1.1 and configure the Visual Studio 2010 project to get the include files from the right places. In the resources folder there is a image that will be loaded, and in the SaraVisualControl.cpp line 20, you have to place the right path to the image, sorry I didnt made this automatic, but I was in a hurry to pack this in a small project. Any other questions about how to run it, please let me know.
EDIT 2
I found this old thread: http://code.opencv.org/issues/2218 the user appears to have the same problem as I have, and just running CMake with OPENCV_CAN_BREAK_BINARY_COMPATIBILITY turned off appears to solve it. But this option is no longer present in the new versions of OpenCV, as stated here http://code.opencv.org/issues/2358. Does anyone knows the implications of this and how it may be related?

Answer 1

I encountered similar symptoms in the past, when mixing VC runtime versions. If you're working in VC2010 and OpenCV 2.4.8 was built on 2012 or even 2013, your ABI does not match. E.g., the layout in memory of std::vector is different, maybe the order of some methods in a vtable somewhere changed, etc.
An easy way to test this is to inspect the 'Modules' window while debugging and look for runtime dll's of a later version. Yours is msvcr100d.dll, if you see msvcr110d or 120d - this might be the source.
(assuming both you and OpenCV link dynamically to the CRT - which I cannot tell).

Answer 2

The debug and release are different in memory allocations. Usually in Debug mode that allocs are bigger.
May be you abuse some openCV call, but you don't aware of it.
I would do next actions:
Validate that the frame is ok. May be it is too big, or width or height are not initiated;
Validate that after next line the image var is OK
Mat image = Mat(frame.height(), frame.width(), CV_8UC4, rame.scanLine(0));
Is it OK to call cvtColor while the 1st and 2nd param are the same (may be you abuse the CV here)
Is it OK to call GaussianBlur while the 1st and 2nd param are the same? Try to put different 2nd param
The same is with threshold function call
Check that after image.clone call, the countoursImage is a valid matrix.

Answer 3

I'm guessing: In addition to checking that the libraries are all correct themselves, check that you specify all libraries in the same order (in all builds). Otherwise, the linker might bind function names to different implementations during the final linker stage.

Answer 4

I had the same issue.I was using Qt 5.1.1 and opencv248 and my application was crashing after returning from findcontours. Turns out I was using the vc10 libs in the pro file and the corresponding dlls whereas the Qt compiler being used was msvc2013. Switching to the vc12 folder in opencv 248 solved the problem for me.

Answer 5

Have you checked your opencv libraries for Release version.
Opencv has different set of libraries for Release and Debug version. if you have accedently included debug libraries in the release mode. your code will compile with no error but will throw excecption when executed.
To check your libraries goto
Project->Properties->Configuration Properties->linker->Input->Additional Dependencies.
make sure none of your Opencv libraries ends with "d" for release mode.
library for Release : 'opencv_core248.lib'
library for Debug : 'opencv_core248d.lib'
notice the d at the end for debug mode.
I hope this would be helpful.