Crashes when using "Open..." #28
Comments
|
So far I'm not able to reproduce that bug. I guess it's related to a particular KIO slave that I don't have. Do you have something like a gdrive mount ? |
|
Could you tell me the protocols used by the remotes hidden under your black bars ? |
|
Remote: one is the standard k4dirstat 3.1.4 used to work without crashes. |
|
Looks like this is where the dialog gets created: Lines 413 to 414 in e4d350d So I tried to replicate it, made a small Qt app: #include <QApplication>
#include <QDebug>
#include <QFileDialog>
#include <QObject>
#include <QPushButton>
int main(int argc, char *argv[])
{
QApplication a(argc, argv);
QPushButton button("Open...");
QObject::connect(&button, &QPushButton::clicked, [&](){
qDebug() << QFileDialog::getExistingDirectoryUrl(&button);
});
button.show();
return a.exec();
}yet it works just fine, without crashes, and prints the QUrl to console. It also shows all my hard drives.
|
|
This PR sounds like my issue #27. |
|
Didn't notice that the PR got merged, new release created and the package updated on Debian. Just checked the 3.2.1 version and it no longer crashes! Thank you @jpalecek and @jeromerobert! |
When opening k4dirstat from applications menu and clicking on "Open...", an empty file picker dialog window appears and k4dirstat crashes.
(Black bars is me censoring things).
Stacktrace indicates that the crash happens in
QStandardItemModel::itemFromIndexWhen running from console with no arguments k4dirstat opens the dialog window right away, crashing right away, printing the following to the console:
However, it works as expected, without crashes, if you run it from console and specify a path as an argument. Of course, clicking on "Open..." to invoke the dialog window makes it crash again, but at least that's some workaround.
That's k4dirstat 3.2.0 as packaged in Debian Testing, using with KDE Plasma as DE, if that matters as far as file picker dialog windows go.
No other application crashes when opening a file picker dialog window, e.g. Kate's "Open..." works just fine.
The text was updated successfully, but these errors were encountered: