Why do I compile the same code on the Visual Studio and Qt, but get different results?

Question

Here is the thing. I was re-writing my OpenCV code on Qt framework these days, and the code runs well on the Visual Studio 2013, but when I run it on the Qt, something weird happend.

To simplify the problem, I write another code to do experiment, and expectedly, the problem still remains.

Here is the code,

#include <iostream>
#include <highgui.hpp>
#include <core.hpp>
#include <cv.hpp>

using namespace std;
using namespace cv;

int main()
{
    Mat view, viewGray;
    vector<Point2f> pointBuf;
    Size boardSize;
    boardSize.width = 7; boardSize.height = 9;
    view = imread("G:\\C++\\OpenCV\\OpenCV\\left1.jpg", 1);
    cout << pointBuf.size() << endl;
    cout << boardSize << endl;
    cvtColor(view, viewGray, COLOR_BGR2GRAY);
    bool found = findChessboardCorners(view, boardSize, pointBuf, \
        CV_CALIB_CB_ADAPTIVE_THRESH | \
        CV_CALIB_CB_FAST_CHECK | \
        CV_CALIB_CB_NORMALIZE_IMAGE);
    cout << pointBuf.size() << endl;
    cout << found << endl;

    namedWindow("show", CV_WINDOW_NORMAL);
    imshow("show", view);
    waitKey(0);

    return 0;
 }

when I run it on Visual Studio, everything is ok. The debug results are as follow.

Debug info on VS2013:

The size of pointBuf before the line bool found = findChessboardCorners(...) is 0 , and then it turns into 63 after that line.

But when I run it on Qt, the debug result turns into very ridiculous,

The code before namedWindow("show", CV_WINDOW_NORMAL); runs without any warning but get a different result, the size of pointBuf before the line bool found = findChessboardCorners(...) is also 0, but it turns into a very huge number after that line, which is 4294044375.

but after namedWindow("show", CV_WINDOW_NORMAL);, another problem occurs,

:-1: error: Exception at 0x778a768b, code: 0xc0000005: read access violation at: 0x0, flags=0x0 (first chance)

and the whole debug info is as follow,

Debug info on Qt:

OS: windows 10 64-bit

Qt Vision: Qt5.6.0 with MSVC 2013

Visual Studio Vision: Visual Studio 2013.

OpenCV Vision: OpenCV3.0

update: I intialized some variables , and the problem is still there.

update 2: @Miki think that I am using the wrong OpenCV libs, (e.g.,using debug libs in release), so I give out all my configuration information as follow, hope someone can do me a favor.

QT += core
QT -= gui

CONFIG += c++11

TARGET = testApp
CONFIG += console
CONFIG -= app_bundle

TEMPLATE = app

SOURCES += main.cpp

INCLUDEPATH +=F:\opencv\build\include \
    F:\opencv\build\include\opencv \
    F:\opencv\build\include\opencv2

LIBS +=F:\opencv\build\x86\vc12\lib\opencv_ts300.lib \
    F:\opencv\build\x86\vc12\lib\opencv_ts300d.lib \
    F:\opencv\build\x86\vc12\lib\opencv_world300.lib \
    F:\opencv\build\x86\vc12\lib\opencv_world300d.lib

update3: I re-compile the opencv libraries, and then do the same test as above, this time I get size of pointBuf is 1638 not 4294044375. So I am sure that the problem comes from the OpenCV itself.

update4: well, this problem has been solved by myself. I changed the opencv vision from 3.0 to 2.4.12, then the whole world calmed down. So I was right, the problem comes from opencv itself.

update5: @Miki was right , I did use the wrong libs. I forgot clear the project first yesterday, that's the reason that I did what @Miki told me but it dosen't work. Thx @Miki

Sounds like you have undefined behavior due to an uninitialized pointer somewhere. — πάντα ῥεῖ, Apr 23 '16 at 07:05
My guess would be uninitialized variables, too (not necessarily pointers, but also e.g. int). In VS you might happen to build in debug mode with variables being initialized with 0 and in QtCreator you might have chosen Release, where they then aren't initialized. If your code builds on OS X or Linux, I'd execute it using valgrind there. — Frank Osterfeld, Apr 23 '16 at 07:56
well, I initialized all the variables , but the same error is still there. — X.S. Wang, Apr 23 '16 at 08:47
The problem somewhere in `findChessboardCorners`, so nobody except you can solve this problem. — fghj, Apr 23 '16 at 08:56
Gosh, `findChessboardCorners` is an OpenCV function. Maybe I should try to change a compiler. — X.S. Wang, Apr 23 '16 at 09:09
It seems that in Qt you're using OpenCV debug libs in release, or viceversa. Please double check your linked libraries — Miki, Apr 23 '16 at 11:02
gosh, maybe that's the point!! but I am knew to Qt, so I dont know how to check. I will give out all my `.pro` info, hope someone can give me some advices. — X.S. Wang, Apr 23 '16 at 14:53
Yep, I was right. Remove the libs with trailing "d", and it will work in release mode. Viceversa for debug — Miki, Apr 23 '16 at 19:44
@FrankOsterfeld: Visual C/C++ does not initialize variables to 0 in debug mode (unless the variables are required to be initialized to 0). It actually initializes variables with values that are designed to help catch bugs, not hide bugs: http://stackoverflow.com/a/370362/12711 — Michael Burr, Apr 25 '16 at 04:06
@Michael Burr: behaviour differs between debug and release, tested here with MSVC 2013: `struct A { int b; }; ... A a;` `a.b` is 0 in debug mode and has a random value in release mode. — Frank Osterfeld, Apr 25 '16 at 05:47
@FrankOsterfeld: If `a` is a global variable, then `a.b` is zero initialized. Perhaps some optimizations in the release build are deferring or eliminating that for some reason (your example doesn't make it clear precisely what might be happening). My point is that the zero initialization in debug builds isn't because of a debug build, but that a global variable is specified by the C standard to be zero initialized. — Michael Burr, Apr 25 '16 at 06:45
@Michael Burr: `A a;` is a local variable in main(), so not a global variable. Thus it's not mandated by the standard to initialize or not (and no other compiler I know does it). I print a.b afterwards, so the value is used (same effect if I use it in a calculation). So MSVC debug builds *do* differ in behavior from release builds, with indeterminism only occurring in release builds, which makes it hard to debug. — Frank Osterfeld, Apr 25 '16 at 07:12
@FrankOsterfeld: I don't know what to say - I don't see the behavior you mention. In fact, I have to 'trick' the compiler to even build a program that prints the uninitialized variable (by putting an initialization inside an `if` that will always be false), otherwise I get an "error `C4700`: uninitialized local variable 'a' used" — Michael Burr, Apr 25 '16 at 14:23
@Michael Burr: Are you compiling with WX? I get a warning, but no error, which I can make disappear with an empty ctor A() (not initializing the members). But now that I'm making my example more complex, it's getting more confusing and it seems that the value being initialized to 0 in debug mode was just a coincidence (although totally reproducible for that example). My information might be outdated, there's plenty of hits about people complaining about MSVC initializing variables to 0 in debug mode, but most of the are 5 years or older. — Frank Osterfeld, Apr 25 '16 at 19:36
You've answered your own question. Please write an answer yourself and accept it, please. — TriskalJM, Apr 29 '16 at 21:00

score 0 · Accepted Answer · answered Apr 30 '16 at 03:43

Well, I am sorry I didn't add an answer immediately when I had the solution.

The problem comes from the wrong using between debug libs and release libs.

Here is the correct configuration,

CONFIG(debug, debug|release)
{
    LIBS +=F:\opencv30\build\x86\vc12\lib\opencv_ts300d.lib \
    F:\opencv30\build\x86\vc12\lib\opencv_world300d.lib
}

CONFIG(release, debug|release)
{
    LIBS +=F:\opencv30\build\x86\vc12\lib\opencv_ts300.lib \
    F:\opencv30\build\x86\vc12\lib\opencv_world300.lib
}

Lastly, I am very grateful for all of you guys' help, and here is the most warm hearted community I have ever been. Thx, everybody.

Why do I compile the same code on the Visual Studio and Qt, but get different results?

1 Answers1