reordering of files in Nav panel crashes Sigil (Linux)

[st_albert]

Just for the record, I'm running kubuntu 18.04, sigil 0.9.9 (built from source) and loaded Qt 5.9.5, and I experience this crash.

I'm not sure why I never noticed it before, since every time I make an epub I generate a toc.xhtml (which ends up as the first file, of course) and move it down to just before the text of the book starts. (i.e. the end of the frontmatter). Now, that causes the crash as described above.

Might be because I only just recently ugraded kubuntu from 16.04.x to 18.04.1.

In any event, adding "XDG_CURRENT_DESKTOP=XFCE" to the sigil startup file fixes the problem.

Albert

[DiapDealer]

At the very least, I think I'll add that line (commented out) to Sigil's launch script. That way, we can tell tell people who have problems on KDE to simply uncomment the line.

This is more evidence (IMO) that the problem lies with KDE's qt platform plugin.

In the meantime, I'll fire up a KDE VM and see if I can't find a workaround that doesn't involve "tricking" Qt into thinking it doesn't need to load KDE's platform plugin.

[KevinH]

Where can I find the source code to the KDE Qt plugin? I think we should search its code base for where that exact error message is generated.

Originally Posted by Banjo

OK. Well that is three distros now that have reported the problem, Mageia 6, PCLOS, and now Debian.

It looks like the Sigil code sets up the QTreeView and then Qt takes over for the drag and drop. I put some printf's in the code in OPFModel::RowsRemovedHandler() to see how far it got. After I drop the file in its new location, I see a bunch of the errors:

Trying to construct an instance of an invalid type, type id : xxxxxxx

and then the GUI is locked up.

If I recall correctly, the execution never got to the OPFModel::RowsRemovedHandler() method, where the Spine Order is updated. So it is locking up before Sigil gets it back. I would have to double check that to confirm; my memory is vague on that.

Anyway, it looks like Sigil sets up the QTreeView and then Qt handles it.... incorrectly.. and after that the interface is partially locked up.

[KevinH]

Googling that error message gets me this Qt bug report:

https://bugreports.qt.io/browse/QTBU...iewStatus=Open

Which only hits KDE and seems to involve Icons.

That specific error message is generated here according to google:

https://code.woboq.org/qt5/qtbase/sr...riant_p.h.html

and again here:

https://code.woboq.org/qt5/qtbase/sr...riant.cpp.html

And here is a very simple standalone Qt program that can be built easily and shows the same issues via drag and drop of items with icons but only under KDE, otherwize the program works fine.

https://gitlab.com/bugpocs/WidgetListCrash

So the Icon is being stored in a QVariant but something is creating a bad QVariant type?

[KevinH]

What do you want to bet this is related to the KDE Qt plugin using is own icons for Folders and HTML files that are different from those that are standard in Qt?

[KevinH]

Originally Posted by KevinH

And here is a very simple standalone Qt program that can be built easily and shows the same issues via drag and drop of items with icons but only under KDE, otherwize the program works fine.

https://gitlab.com/bugpocs/WidgetListCrash

Would someone on Linux with access to KDE please build this small testcase using qmake and verify that it only has issues with KDE and not other Desktops.

Thanks,

KevinH

[DiapDealer]

Originally Posted by KevinH

What do you want to bet this is related to the KDE Qt plugin using is own icons for Folders and HTML files that are different from those that are standard in Qt?

It's a good bet. It probably affects what QFileIconProvider.icon(QFile) returns (which is what we use to assign the icon in Resource.cpp).

[KevinH]

Here is an interesting link that shows up to May 2017 QFileIconProvider did not even work under plasma, it returned an empty pixmap...

https://phabricator.kde.org/R135:7a7...e6e8aabe45b7ed

[DiapDealer]

And that's just last year! But at least some portions of QFileIconProvider have to be working. Afterall... it's used to initialize the tree in the first place. All of the folder icons and the initial file icons are successfully retrieved via QFileIconProvider in OPFModel.cpp and Resource.cpp. It's only after reordering that things blow up in KDE

I believe QFileIconProvider has some flags that can be set to limit it to default icons only. I wonder if that's worth exploring?

[DiapDealer]

Originally Posted by KevinH

Would someone on Linux with access to KDE please build this small testcase using qmake and verify that it only has issues with KDE and not other Desktops.

Thanks,

KevinH

Crashes immediately when dragging an item with an icon on Kubuntu 16.04, but hasn't crashed for me on a non-KDE DE yet.

[KevinH]

Wow ... It is a very simple testcase! The backtrace from the original bug report did not show any Plasma/KDE info so the KDE people ignored it and asked the original poster to file it at Qt so nothing was ever done as far as I can tell.

Well at least with this testcase we are now certain that the problem has nothing to do with Sigil.

I am going to go over that testcase to see how file Icons are being set in case that points us someplace.

Thanks for building and running the testcase!

[KevinH]

FWIW, the implementation in the KDE plugin for QFileIcon provider uses fromTheme as well:

	QIcon KdePlatformTheme::fileIcon(const QFileInfo &fileInfo, QPlatformTheme::IconOptions iconOptions) const
114		{
115		    if (iconOptions.testFlag(DontUseCustomDirectoryIcons) && fileInfo.isDir()) {
116		        return QIcon::fromTheme(QLatin1String("inode-directory"));
117		    }
118		
119		    return QIcon::fromTheme(KIO::iconNameForUrl(QUrl::fromLocalFile(fileInfo.absoluteFilePath())));
120		}

And the simple testcase does the following:

QListWidgetItem *firstItem = new QListWidgetItem(QIcon::fromTheme("dialog-information"),
                                                     "ONE");

So my guess is that QIcon routine is or its themed version is where the trouble may be.

[KevinH]

Or given it works initially (the File Icon shows up) it might be related to QIcon cacheing code someplace as well.

[Banjo]

I compiled and ran WidgetListCrash on my Mageia system. It crashes when I move an item with an icon. It also duplicates the items when I drag items with no icons. See attached screen capture.

[DiapDealer]

The duplication thing is expected. There's no copy/remove code implemented in the test. It's just simply illustrating the drag/drop crash and nothing else.