[SOLVED] Application works fine in debug mode, but not in release mode

jellyv

I have a code where I loop through QHash and give its values to different variables. In QT Debug mode, everything works fine. However, in QT Release mode, QT fails to get the values of the first QHash element. I'm not 100% if this is QHash's fault, though.
I'm getting no errors while running the code, but I am getting these errors while debugging:(not sure if they are related to my problem)

Sometimes debugger shows these errors in application output:

onecoreuap\shell\ext\thumbnailcache\lib\thumbcacheobj.cpp(1843)\thumbcache.dll!79DF1802: (caller: 79DE0069) ReturnHr(1) tid(30fc) 80070102 The wait operation timed out.
    CallContext:[\InitializeCache] 
shell\osshell\lmui\ntshrui\dll\shrengine.cpp(1487)\ntshrui.dll!5D88564E: (caller: 5D880B84) ReturnHr(1) tid(449c) 80004005 Unspecified error

Sometimes it shows these errors:

mincore\com\oleaut32\dispatch\ups.cpp(2125)\OLEAUT32.dll!77004231: (caller: 77004328) ReturnHr(1) tid(600) 8002801D Library not registered.
shell\osshell\lmui\ntshrui\dll\shrengine.cpp(1487)\ntshrui.dll!5D88564E: (caller: 5D880B84) ReturnHr(1) tid(2d58) 80004005 Unspecified error

I know that not initializing the variables might cause this problem, but I'm initializing all the variables (except for QList and QHash. could you tell me what's the best way to initialize these?)

QT Info:
QT Creator 3.6.1
Based on QT 5.6.0 (MSVC 2013, 32 bit)
Compiler: mingw49_32
OS:
Windows 10 Pro x64

jellyv

Hi everyone, Sorry for the late reply.
As I could not use debugger in release mode, I decided to print various variables using std::cout at the "breakpoints". I tracked down the problem and discovered that I was declaring a boolean in the header file, and then again in the .cpp file. QT should've warned me about it but it didn't. In release mode, when boolean was true, its value became 260. It seems that if boolean's value is above 1, it is changed to 1 in debug mode, but not in release mode, causing the program to crash.

To anyone with similar issue, I recommend setting "breakpoints" in application output using std::cout and tracking down the problem that way. Or as @kshegunov said, use profile mode.

JonB

@jellyv
I don't think those messages will be anything relevant, just the debugger picking them up from OS.

Yes it sounds quite possibly like some uninitialised variable. But you have to show some relevant code. QList & QHash come initialised to empty, which is fine. It's a question of what you then put in them and how you access them.

QT fails to get the values of the first QHash element. I'm not 100% if this is QHash's fault

That does not sound good. I'm quite sure it isn't QHash's fault though :)

mrjj

Hi
Those look like some errors/warnings in windows with QFiledialog
https://bugreports.qt.io/browse/QTBUG-52618

So i agree i dont think they relate to your issue.

Its hard to guess at what could be wrong in release mode.
Is it possible to show code ?

gde23

Crashing in release and not debug is almost always because of writing data to unitialized memory, e.g. writing over the end of an array.
On Linux you can use valgrind to check for the leaks and see in which function they occur. On Windows there exist similar tools but I don't know them.

JonB

@gde23
To be exact, I think it's only fair to say that is writing to unallocated memory, rather than uninitialized, which are of course different things. Reading from or writing to unallocated memory via a pointer which is either uninitialized or set to a bad value can cause crash. Writing over the end of an array tends to work in itself, but blats some area which later causes a crash when it is used as supposedly containg a valid pointer.

kshegunov

@jellyv said in Application works fine in debug mode, but not in release mode:

I have a code where I loop through QHash and give its values to different variables. In QT Debug mode, everything works fine. However, in QT Release mode, QT fails to get the values of the first QHash element. I'm not 100% if this is QHash's fault, though.

Pretty sure it's not. Compile in release with debug info (a.k.a. profile mode) and extract the backtrace of the crash. Then please provide the code around the place which crashes in your code (along with the actual trace).

I know that not initializing the variables might cause this problem, but I'm initializing all the variables (except for QList and QHash. could you tell me what's the best way to initialize these?)

They're initialized automatically. All Qt types comply with RAII, but in any case show us how you declare and use the two variables at least.

@gde23 @JonB

You're both correct in the sense you're both wrong. ;)
I'm joking of course. Strictly speaking it's writing past the segment/page/block you own, that's what causes a "segmentation fault"/"access violation"/"irrecoverable page fault". Smashing the stack also falls into this category.

For example I had the following fly through debug, but crash beautifully in release (on windows only):

class SomeClass
{
    SomeClass(const OtherClass & o)
        x(o)
    {
    }

    void oops() const
    {
        x.getStuff();
    }

    const OtherClass & x;
}

SomeClass z(OtherClass()); //< Capturing a temporary by a const reference
z.oops(); //< Ooops, indeed.

And as references are just glorified pointers that was compiled as a dangling one.

jellyv

Hi everyone, Sorry for the late reply.
As I could not use debugger in release mode, I decided to print various variables using std::cout at the "breakpoints". I tracked down the problem and discovered that I was declaring a boolean in the header file, and then again in the .cpp file. QT should've warned me about it but it didn't. In release mode, when boolean was true, its value became 260. It seems that if boolean's value is above 1, it is changed to 1 in debug mode, but not in release mode, causing the program to crash.

To anyone with similar issue, I recommend setting "breakpoints" in application output using std::cout and tracking down the problem that way. Or as @kshegunov said, use profile mode.

kshegunov

That's fine and I'm glad you found your problem, but this:

QT should've warned me about it but it didn't.

is simply wrong. Qt is a library, it has no role in warning you about anything but abuse of its own API. You may make an argument about the compiler you're using, but then again ... well it's tricky business what constitutes a thing worth a warning and what is intended as is.

SGaist

Hi,

There's no reason for Qt which is a framework to warn about anything of that kind. It could be a compiler warning but not Qt. There's nothing in the C++ specs that says you are not allowed to use function local variable with the same name as class variable although I agree it's a bad idea.