https://bugs.kde.org/show_bug.cgi?id=397040
Friedrich W. H. Kossebau <kosse...@kde.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kosse...@kde.org --- Comment #5 from Friedrich W. H. Kossebau <kosse...@kde.org> --- (In reply to Pino Toscano from comment #4) > (In reply to zccrs from comment #3) > > Created attachment 114347 [details] > > This is a stack list > > This shows that the issue is not in the EPS handler, which is called for > some reasons during the application destruction. "Some reason" might be the interesting part here though. Seems that the clipboard wants to rescue the current content the application has set on the clipboard, instead of deleting it together with the process ending, and tries to pass it to the X clipboard manager, which might be by design. Now it just happens that from all the possible QImageIO plugins which can write it picks the EPS one. Which would be a rather bad pick in general, but it seems QInternalMimeData::hasFormatHelper() simply picks whatever is first in the list. And as the EPS plugin has not been written to be run at this destruction stage, things are flawed. Not sure if the result of QImageIOPlugin::capabilities() is cached, or queried dynamically. But if queried dynamically, there should be a check here to deny any abilities if there is no QCoreApplication, as of course doing so in the actual read/write handlers would be too late. At least by a quick look following the call chain from https://code.woboq.org/qt5/qtbase/src/gui/kernel/qdnd.cpp.html#293 to https://code.woboq.org/qt5/qtbase/src/gui/image/qimagereaderwriterhelpers.cpp.html#119 hints the list of qimageio plugins is always dynamically queried here. So while still curious why the EPS handler is picked here, being prepared for this situation seems not a useless thing to do. > The problem is the deepin stuff, including its usage of an internal part of > Qt (the Qt5XcbQpa library). Try the test case of comment 2 without any > deepin stuff installed. Though most of the stacktrace looks fine, a call stack which would just happen with normal QGuiApplication destruction as well, which only deletes the platform integration plugin in the ~QGuiApplicationPrivate destructor. -- You are receiving this mail because: You are watching all bug changes.