QFileDialog::getOpenFileName causing program to crash

JonB

@crackysk said in QFileDialog::getOpenFileName causing program to crash:

Since application has been working for years (3 more precisely) before this without any issues, my guess would be that some kind of Windows (also using Win10) update messed something up, but can't be sure about it.

It is highly likely this is the case, sadly. I don't know what you can do about it (sometimes it's possible the next patch/update corrects an issue), but you might verify:

I think it's clear the error comes when using the native Windows Save File dialog. Try passing QFileDialog::DontUseNativeDialog? But I'm not sure that works with getSaveFileName(), you may also have to try...
... Use a QFileDialog instance and setAcceptMode(QFileDialog::AcceptSave) to try your own code instead of the inbuilt static QFileDialog::getSaveFileName().

At least you will know what is required to reproduce the issue.

crackysk

@JonB
I've tried first option before posting yesterday, but forgot to mention it (knew I would forget something).
Today I tried the approach with using QFileDialog instance and still have same issue.

One interesting thing is that with QFileDialog::DontUseNativeDialog set to false application works "slightly better". Let me try to elaborate:

When set to false, Windows dialog opens fully, shows a content of starting location folder, but then freezes and runs send problem report mechanism
When set to true, something I believe should be Qt dialog opens, but dialog is fully white without any useful information and instantly runs send problem report mechanism

Will try to play further with it and see if I can make it work somehow.
Thank you for your replies and time.

LaCucaracha

I've had the same issue in the last few days and managed to get around it.

I've had the same backtrace as shown above. On an app that worked for years. Qt 5.9 and now 5.15. Windows 10.

I don't use a QFileDialog but a QFileSystemModel set into a QTreeView.
When there is nothing to display, there is no crash (TreeView hidden, Model not set or Rootpath and Filters set to display an empty location).

My solution was to remove the icons from the display by overriding the function data() of QFileSystemModel to ignore the Qt::DecorationRole :

QVariant MyCustomFileModel::data(const QModelIndex& index, int role) const
{
    if (role == Qt::DecorationRole)
        return QVariant();
    else
        return QFileSystemModel::data(index, role);
}

No icons. But it works.

Digging further, i made my own QFileIconProvider to give to the model.
The function icon is the issue.

QIcon QFileIconProvider::icon(const QFileInfo &info) const

If i override it to return QIcon() it works fine, with icons. They might be different from what they were before and there might be some missing ones but i'm not sure. Probably has to do with the style of the application. (No custom style applied here)

For the next step, looking into QFileIconProviderPrivate, QGuiApplicationPrivate and QPlatformTheme might be a bit too much for my skills.

Also, the options QFileIconProvider::DontUseCustomDirectoryIcons and all of the QFileSystemModel options (DontWatchForChanges, DontResolveSymlinks, DontUseCustomDirectoryIcons) do not change anything.

crackysk

@LaCucaracha

Thank you for reply. I even tried QFileIconProvider::DontUseCustomDirectoryIcons at some point, but didn't cross my mind that's not doing anything useful.

I tried providing icon provider directly to static QFileDialog for save/open file that I was using, but it made no difference. Also, creating custom FileIconProvider and providing it to instance of QFileDialog created in app made no difference (also creating custom QFileDialog class).
So, I basically moved to same thing as you did. I've written my own dialog that's doing same thing as static one I was using before.
Now, I have treeView and listView next to each other, both of them provided with different QFileSystemModel (different when it comes to filter) and provided custom QFileIconProvider class that has icon() overridden. And really, crashes are gone!

Honestly, I don't even mind having same file icon for each file type. For purposes I need it for, this is more than enough. But, if someone needs it, probably can even do similar thing like you did for a role and look for a specific QFileInfo that makes a mess and for all others use just default constructor for QIcon as you did.

All that's left to do is handling cosmetics in order to make this new QDialog as close as possible to the one.

Vsevolod7

Same problem.

? Offline

I copy your codes and run it on win11 successfully. I used Qt5.13 and the compiler 'MingGW 64bit'. Add I tried the compiler 'MSVC2015', it is all right too. I think our developing environment are similar to each other.

az1699

Same issue here. I've a test application made few months ago that always worked. I fixed by working around using DontUseNativeDialog.

If I run the same application, same build, on windows sand box it works perfectlly. Dont know why, windows sand box should have the same windows system update as my system

az1699

I also tried this, don't why but after istancing QFileDialog with QFileDialog::DontUseNativeDialog I can start using QFileDialog in the previous way. I tested this simple example and works.

    static bool first_run = true;
    if (first_run) {
        CmdOpenFile(QFileDialog::getOpenFileName(0, "Open some file", QString(), QObject::tr("All files (*.*)"), nullptr, QFileDialog::DontUseNativeDialog));
        first_run = false;
    } else {
        CmdOpenFile(QFileDialog::getOpenFileName(0, "Open some file", QString(), QObject::tr("All files (*.*)")));
    }

Violet Giraffe

I can't speak for every case in particular, but these symptoms are very typical for a misbehaving shell / Explorer extension, and not related to Qt, most likely.

I've seen some projects (for example - Firefox) maintain a list of known faulty DLLs and use LoadLibrary hooks to prevent those DLLs from loading.

sir_clive

I'd like to add my experience with this issue.

I pulled my hair out over a very similar (probably the same?) problem lately, and it turned out that AVAST and AVG (practically the same product) are causing this problem in my case. These programs must be uninstalled (not deactivated, but completely uninstalled) for my program to start working again.

My program was working on multiple versions of Windows for years already, with no issues whatsoever. The problems started in February this year (2023), and affect every single "file dialog" instance my program tries to open.

The tip with not using native dialog did not help in my case. Also VMWare based Windows installations are not affected, only the "bare metal" ones. Also, 5.x and 6.x QT versions are both crashing if AVAST or AVG are installed.

I'm surprised not more QT programs are affected, this is the best thread I found so far.

az1699

@sir_clive I've Avast antivurs on my computer, i tested in an other without avast and works :(

So maybe reporting this issue the could fix it

QtWS: Super Early Bird Tickets Available!

QFileDialog::getOpenFileName causing program to crash