Windows 10 error "instruction at referenced memory" from Qt application

[Niagarer]

This beautiful application error instruction at 0x0000000061982632 referenced memory at 0x0000000000000008. The memory could not be read occurs when I try to shutdown my pc.
The error comes from my Qt application which I already closed (I also closed Qt Creator and every other program). Maybe I should avoid behaviour like that in my program ... :)
Does anyone know, where exactely this error comes from and how I can avoid that?

Visual Studio debugger:

well Qt5Gui.dll really limits the problem ... not

[Niagarer]

Update for anyone experiencing the same in the future:
A bug of Qt was causing the process to remain active after closing the window when placing QGraphicsProxyWidgets in a QGraphicsScene.
Bugreport
It's closed in Qt 5.14.1+
Newer thread where this was mentioned

[mrjj]

Hi
Thats very hard to guess at. Looks like a dangling pointer.
Do you use threads in your app ?

[Chris Kawa]

The error comes from my Qt application which I already closed

Apparently not. If it crashes it is still very much running. Probably spins an empty event loop if all windows are closed. Might be a problem in how you handle closing the app.

Looking at function addresses won't tell you much. Either try a debug build or download debug symbols for the release libraries. If you installed Qt via the online installer you can run the maintenance tool again and check the Qt Debug Information Files option in the version selection tree. After that right click on any of the addresses in the call stack window and Load symbols.

Even so, I'd expect the bug to be in your code (in the vScript_060.exe), so you should load debug symbols for that too if you have them or generate them if not.

[Niagarer]

@Chris-Kawa
Ok, thanks for the detailed instructions, I will follow your suggestions and update here.
Anyway, I am slightly confused, because when I run the project (vScript_60) in Qt Creator and close the window, it shows vScript_60.exe exited with code 0, so there shouldn't be anything running anymore, right?
The error only occurs by opening the exported version of the project (exported via windeployqt). But of course you are right, after closing the exported version, there is still a vScript_60.exe thread running. So the Qt debugger seems to do things, the exported version doesn't. Why?

@mrjj
I am using a QThreadStorage, could this be a problem?

in myqts.h

void ltsRegisterObject(const QString &key, QObject *object);
void ltsRemoveObject(const QString &key);
QObject* ltsGetObject(const QString &key);
template <typename T> T* ltsGet(const QString &key) {
     return qobject_cast<T*>(ltsGetObject(key));
}

myqts.cpp

#include "myqts.h"


static QThreadStorage<QMap<QString, QObject*> > s_qtObjects;

void ltsRegisterObject(const QString &key, QObject *object)
{
    s_qtObjects.localData().insert(key, object);
}

void ltsRemoveObject(const QString &key)
{
    if (!s_qtObjects.hasLocalData())
        return;

    s_qtObjects.localData().remove(key);
}

QObject* ltsGetObject(const QString &key)
{
    QObject *object;
    auto it = s_qtObjects.localData().find(key);
    return it != s_qtObjects.localData().end() ? it.value() : nullptr;
}

in mainwindow.cpp, I add it to the storage

ltsRegisterObject("mainWindow", this);

and I only use this in a form class

auto* pMainWnd = ltsGet<MainWindow>("mainWindow");
    if(pMainWnd)
        static_cast<MainWindow*>(pMainWnd)->setUpCodeNodes();

I didn't think, there could be a problem here, the documentation sais, that "QThreadStorage deletes all data set for the main() thread when QApplication is destroyed"

[Chris Kawa]

How is the MainWindow object created? Do you destroy it manually? If it's created on the stack (which is common for main windows) then it would be a double delete bug and source of that crash.

So the Qt debugger seems to do things, the exported version doesn't.

There' s no such thing as Qt debugger. Qt Creator (the IDE) is using whichever toolchain and debugger you set it up with (e.g. MSVC+CDB or MinGW+GDB). Are you running a debug or release version of the app in the IDE? If debug then it's normal that it behaves slightly different than the release version you run outside of the IDE. One noticeable difference is that debug builds tend to zero initialize some variables so a common bug that occurs in release builds but not in debug is accessing uninitialized variable, e.g. a garbage pointer. The other is when you're using multiple threads. The debug builds have an overhead that makes the thread timings vary a lot from those in release builds.

[Niagarer]

@Chris-Kawa said in Windows 10 error "instruction at referenced memory" from Qt application:

How is the MainWindow object created?

Yes, it's created on stack and the destructor of MainWindow just deletes the ui as usual and I don't destroy the MainWindow manually

There' s no such thing as Qt debugger. Qt Creator (the IDE) is using whichever toolchain and debugger you set it up with (e.g. MSVC+CDB or MinGW+GDB).

Yes, sorry, in my case MinGW 7.3.0 with GDB for Qt 12.0

Are you running a debug or release version of the app in the IDE?

I just tried both and both result in the same behaviour.
I noticed, that the behaviour of the project running in Qt Creator and the exported version do not differ, unlike I wrote above, sorry. There is only a lasting thread if I do something specific, otherwise everything works. The thread only lasts if I click onto a QGrapicsView which causes placing of a bunch of QGraphicsItems (with QGraphicsDropShadowEffect and QGraphicsProxyWidgets) in the scene... I will try to find anything here, but the classes of the stuff I place in the view are huge. Is there something specific that is popular to cause behaviour like this with QGraphicsItem, QGraphicsProxyWidget or QGraphicsDropShadowEffect?

[Niagarer]

Update for anyone experiencing the same in the future:
A bug of Qt was causing the process to remain active after closing the window when placing QGraphicsProxyWidgets in a QGraphicsScene.
Bugreport
It's closed in Qt 5.14.1+
Newer thread where this was mentioned

[Grigg_23]

This post is deleted!