Application crash on startup : error 0xc0000005
-
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).
-
@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. aQFileInfo::exists()
function. AFAIK, theQFileInfo
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 assumeQFileInfo(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.
-
-
@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.
-
@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.
-
This post is deleted!