Application crash on startup : error 0xc0000005

nwoki

Did some more tests, as suggested, removed the QtCharts from the application and tried to force angle with

QApplication::setAttribute(Qt::AA_DisableShaderDiskCache);
QApplication::setAttribute(Qt::AA_UseSoftwareOpenGL);

Without charts

Now the last thing it seems to load before crashing si the QWebProcess.exe file. I tried to run it by itself and it as visible in the process monitor. I then check the process when launched with Qt and I found this:

"C:\Users\user\Desktop\GOFORIT\QtWebEngineProcess.exe" --type=renderer --disable-gpu-memory-buffer-video-frames --disable-shared-workers --enable-threaded-compositing --disable-mojo-local-storage --no-sandbox --use-gl=desktop --enable-features=AllowContentInitiatedDataUrlNavigations

Might this have anything to do with the crash?

I'm starting to begin to think that it's a problem related to the intel drivers of the card as i've found others with problems like mine here and here.

Plus, this is the only computer that presents this problem. My windows machine, and that of my collegues that have a dedicated graphics card, run the application without any fuss.

nwoki

Using windows debugger, I get the following error

ModLoad: 5ed00000 5ed58000   C:\Users\user\Desktop\goforit\qml\QtCharts\qtchartsqml2.dll
(2a38.880): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\Qt5Widgets.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\user\Desktop\goforit\Qt5Widgets.dll - 
*** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\app.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Users\user\Desktop\goforit\app.exe
eax=004ff830 ebx=606ea6e0 ecx=baadf00d edx=00000000 esi=baadf00d edi=00000005
eip=606ea5d1 esp=004ff7d0 ebp=004ff848 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
Qt5Widgets!QAction::setText+0x1:
606ea5d1 8b7104          mov     esi,dword ptr [ecx+4] ds:002b:baadf011=????????

First time I get this sort of error. Anyone know what might be the cause for it?

hskoglund

Hi, that baadfood address in ecx is a fallback value for uninitialized objects on the heap, it could be that you're trying to set the QAction text for a bad QWidget/OpenGL window. Again, this could mean that the Intel graphics driver needs to be updated...

nwoki

So, turns out that the only error message that was telling the truth was the one regarding the QAction : Qt5Widgets!QAction::setText+0x1:.

What was happening was the following:

I've implemented a "Recent files" QMenu where i set the last 5 recent files used by the client. What happened in this particular case was that the client removed some recent files that were stashed by my application (their path url) and so when I want to load them into the menu with:

    for (int i = 0; i < recentFiles.count(); ++i) {
        QAction *rf = m_recentFilesActions.at(i);
        rf->setText(QFileInfo(recentFiles.at(i)).fileName());
        rf->setData(recentFiles.at(i));
        rf->setVisible(true);
    }

the application crashed.

What threw me off was the first part of the debug message

(2a38.880): Access violation - code c0000005 (first chance)
First chance exceptions are reported before any exception handling.
This exception may be expected and handled.
*** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\Qt5Widgets.dll
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Users\user\Desktop\goforit\Qt5Widgets.dll - 
*** WARNING: Unable to verify checksum for C:\Users\user\Desktop\goforit\app.exe
*** ERROR: Module load completed but symbols could not be loaded for C:\Users\user\Desktop\goforit\app.exe

which led me to think it was a problem concerning the graphical driver of the client as he told me he had done some updates lately and that the access error was related to the QWidgets.dll file.

Once I fixed that, the application went back to normal. Thankyou @ambershark and @hskoglund (you're last comment helped me find the problem) for your help. I've also learned a few things on debugging under windows (i'm a linux guy).

JonB

@nwoki

the application crashed.

OOI. What actually crashed? The code you show? Do you mean m_recentFilesActions.at(i) was nullptr/invalid?

nwoki

@JonB The line

rf->setText(QFileInfo(recentFiles.at(i)).fileName());

was the culprit as the QFileInfo was not being created seeing that the recent file had been moved.

JonB

@nwoki
I really do not understand this, for two reasons:

When you try to create a QFileInfo(QString filepath) it does not fail if the path does not exist. If it did, there would be no point in having e.g. a QFileInfo::exists() function. AFAIK, the QFileInfo methods treat the filepath as a string to parse to produce results for extracting segments; they only try to access the file when a function which needs to do so is called. I therefore assume QFileInfo(recentFiles.at(i)).fileName()); would return the filename part of whatever you passed in.
Even if that were not true, then either it would throw some exception possibly or it would return, say, an empty string for the filename. You would pass that to your rf->setText(), and whatever that did it would not "crash" on trying to set some text.

I should be obliged if a Qt expert would correct me if the above is not true? Otherwise I do not see how in itself it would lead to the behaviour you have previously shown, which is why I asked.

Limer

@JonB https://forum.qt.io/topic/93393/gui-operations-are-performed-in-a-non-gui-thread

Hope this helps you.

JonB

@Limer I had no idea a non-GUI thread was involved!

ambershark

@nwoki I'm with @JonB on this ... I don't understand why it's failing.

QFileInfo fi("").fileName() for instance should not crash at all. It's perfectly valid. So if your recents list had a cleaned up file it shouldn't have mattered at all.

I only typically have linux environments to test with and it works fine in linux (but you already knew that). So if it fails in windows that is a Qt bug not a bug in your software. Assuming it's a crash in QFileInfo().fileName() which at worst should return an empty string, not crash.

Glad you got it working but it may be a "fake" fix since there is no reason that should have crashed in windows or elsewhere.

ambershark

@Limer said in Application crash on startup : error 0xc0000005:

thread

There was no mention in this posting about a non-gui thread at all. Not sure where you got that idea.

sadia

This post is deleted!

Awaisserfriz

This post is deleted!