HOW TO Read exceptions

[Sillimon]

Hi there !

I'm working with a library and some part of the code using it working (the program launches but crash after using a specific comboBox).
It already came up in another post but i was quite sure it was a linking problem because my .pro was really messy and full of experimentations.

Now that i cleaned it a little bit, it did not solve anything...

So, I first wonder if it's not a linking problem so it'd be great if someone could tell me if something is wrong with my .pro file.
Personnaly, i read a lot of tutorials and examples and nothing's obviously wrong to me.

.pro

TARGET = MRCFinal

TEMPLATE = app

QT -= gui

CONFIG += c++11
CONFIG += qt warn_on debug #TODO - Change for release before deployment

# The following define makes your compiler emit warnings if you use
# any feature of Qt which as been marked deprecated (the exact warnings
# depend on your compiler). Please consult the documentation of the
# deprecated API in order to know how to port your code away from it.
DEFINES += QT_DEPRECATED_WARNINGS

# You can also make your code fail to compile if you use deprecated APIs.
# In order to do so, uncomment the following line.
# You can also select to disable deprecated APIs only up to a certain version of Qt.
#DEFINES += QT_DISABLE_DEPRECATED_BEFORE=0x060000    # disables all the APIs deprecated before Qt 6.0.0

#dependency
QT += quick widgets qml core

SOURCES += main.cpp \
    comboboxmodel.cpp \
    cardinformation.cpp \
    definition.cpp \
    reader.cpp \
    readwrite.cpp

RESOURCES += qml.qrc

# Additional import path used to resolve QML modules in Qt Creator's code model
QML_IMPORT_PATH =

# Additional import path used to resolve QML modules just for Qt Quick Designer
QML_DESIGNER_IMPORT_PATH =

# Default rules for deployment.
#qnx: target.path = /tmp/$${TARGET}/bin
#else: unix:!android: target.path = /opt/$${TARGET}/bin
#!isEmpty(target.path): INSTALLS += target

HEADERS += \
    comboboxmodel.h \
    cardinformation.h \
    header.h \
    reader.h \
    readwrite.h


#wince*: {
#       SIGNATURE_FILE = $${ISLOGRepository}keys\islog_sign_binary.pfx
#}

#win32 {

    ## Windows common build here

    !contains(QMAKE_TARGET.arch, x86_64) {
        message("x86 build")

        ## Windows x86 (32bit) specific build here
        LIBS += -L$$PWD/packages/lib/Win32
        CONFIG(release, debug|release): LIBS += -L$$PWD/packages/lib/Win32/Release -lliblogicalaccess -lmifarecards
        else:CONFIG(debug, debug|release): LIBS += -L$$PWD/packages/lib/Win32/Debug -lliblogicalaccess -lmifarecards

    } else {
        message("x86_64 build")

        BUILDARCH=x64
        Release:BUILDTYPE = $${BUILDARCH}\\Release
        Debug:BUILDTYPE = $${BUILDARCH}\\Debug

        ## Windows x64 (64bit) specific build here
        LIBS += -L$$PWD/packages/lib/x64
        CONFIG(release, debug|release): LIBS += -L$$PWD/packages/lib/x64/Release -lliblogicalaccess -lmifarecards
        else:CONFIG(debug, debug|release): LIBS += -L$$PWD/packages/lib/x64/Debug -lliblogicalaccess -lmifarecards
    }

INCLUDEPATH += $$PWD/packages/include

May i ask by the way what those lines are made for ?

# Default rules for deployment.
#qnx: target.path = /tmp/$${TARGET}/bin
#else: unix:!android: target.path = /opt/$${TARGET}/bin
#!isEmpty(target.path): INSTALLS += target

Finally, if nothing's wrong on that side, i don't get where the problem come from.

I got the exception "The inferior stopped because it triggered an exception. Stopped in thread 0 by: Exception at 0x7ffff0e453fb8, code 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued).

Does someone know how i can read this kind of exceptions ? Does it at least gives a clue or is it just a random message with memory areas you can't know where they come from ?

Open to any advice/proposititon/own experience and their related observations !
Thankfull

[SGaist]

Hi,

Run your application through the debugger. You'll get the stack trace that leads to the crash.

The "Default rules for deployment" are what is suggested, defaults to be used when deploying your application on these platforms. You can safely ignore them if you don't target these.

[Sillimon]

Hello and thanks for your help !

Actually, I already know on which line the error occurs but i checked multiple times and i don't see anything wrong with it. I don't see anything else than a linking error.

Also, i launched the debugger to see what the application output feedback.

Logs after processing the line making an error :

• Exception at 0x7fff0e453fb8, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) at f:\dd\vctools\crt\crtw32\heap\new.cpp:62

• Exception at 0x7fff0e453fb8, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) at f:\dd\vctools\crt\crtw32\heap\new.cpp:62

• Exception at 0x7fff0e453fb8, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) in liblogicalaccess!logicalaccess::ComputerMemoryKeyStorage::getType

• Exception at 0x7fff0e453fb8, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) (first chance) in ntdll!RcConsolidateFrames

• Exception at 0x7fff0e453fb8, code: 0xe06d7363: C++ exception, flags=0x1 (execution cannot be continued) in ntdll!RcConsolidateFrames

Found the same error on a forum, the solution was : "I figured out the problem, i was mixing a debug version of my program with a release version of the library. Cmake configuration of the library is generating the same name for both build versions. "

Well... same for me ! i didn't know there was any difference between both but that sounds so obvious right now... I even made the difference in the .pro

It leads me to another question... considering the fact that i'm managing 32 and x64 version for both debug and release, what is the difference in a library between those four "versions" of the file ?

The "Default rules for deployment" are what is suggested, defaults to be used when deploying your application on these platforms. You can safely ignore them if you don't target these.

Anyway, thanks for your answer and help (for those .pro lines too ! Indeed, i don't target that kind of platforms for now)

[JonB]

@Sillimon said in HOW TO Read exceptions:

It leads me to another question... considering the fact that i'm managing 32 and x64 version for both debug and release, what is the difference in a library between those four "versions" of the file ?

Not sure what you mean. There are 4 different versions because 2 are 32-bit and 2 are 64-bit, and for each one is for debug and one is for release? That's 4 different sets of binary code.

[Sillimon]

@JonB Yep ! That's exactly what i meant, thanks a lot for precisions !

I should be able to search more details by myself with this =)

[JonB]

@Sillimon
To be clear, each of those binaries is different AND the vital thing is you must not mix or link against any multiple kinds into the same executable --- you must only have everything of one of these kinds, else you will get things like random crashes.

[Sillimon]

@JonB I learnt it the hard way !

So the point is they interact together so they need to "obey" to the same binary category to make that interaction possible.

When you say "only have everything of one of these kinds", do you mean they should respect the binary you choose for your program or can you, theorically, use another binary as long as all the library files use the same binary ?

Like... running your program in debug x64 but using win32 release version for ALL additional files.

I know that's a stupid question (as long as you got the choice, why would you use another type ?) but i think i did something similar before and that would make it clearer.

[JonB]

@Sillimon
As a general rule you pick whether you are targetting 64-bit versus 32-bit, and stick to that.

You pick whether you are targetting Release or Debug versions, and stick to that.

However, it gets complicated, insofar as there are ways to execute 32-bit executables under 64-bit. You can (probably/usually) use Release versions of common library code against your own Debug code.

Unless a Qt/C++ "expert" (not me!) wants to explain in detail, the precisely allowed interrelationships are really complex/long to explain! One pretty firm rule, however, I think is: at minimum, any given "unit" --- which could be your own complete source code, or one complete library --- needs to stick to one pair of 32/64 & debug/release. Plus, you'll probably run into trouble if there is any mixing of 32- & 64-bit (though I think the linker/loader will prevent you from this anyway). That's about it from me... :)

[Sillimon]

@JonB I think i won't be able to understand something more detailled and that answer the whole questions =)

Thanks a lot, you ma real expert ! ;D