#include <QImage> #include <QDebug> int main() { QImage image(100, 100, QImage::Format_ARGB32); qDebug() << image.save("/tmp/test.eps", "eps"); return 0; } Crash at: QPrinterPrivate::init Output: QPrinter: Must construct a QCoreApplication before a QPrinter
Yes, so construct a QCoreApplication, as it says ;-) This isn't a bug.
(In reply to David Faure from comment #1) > Yes, so construct a QCoreApplication, as it says ;-) > > This isn't a bug. This is a bug. If not construct QGuiApplication, the "image.save" should be return false, not thorw a abort and crash. The above list the code is just a simple example to highlight the problem. The following is a normal code, but it still exits abnormally. #include <QGuiApplication> #include <QClipboard> #include <QDebug> #include <QPixmap> int main(int argc, char *argv[]) { QGuiApplication app(argc, argv); QPixmap pixmap(100, 100); app.clipboard()->setPixmap(pixmap); return 0; } Qt=5.10.1 kimageformat-plugins=5.46.0-1 On Debian sid
Created attachment 114347 [details] This is a stack list
(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. 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.
(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.
(In reply to Friedrich W. H. Kossebau from comment #5) > (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. I think so too.
(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. > > 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. The problem no association of deepin desktop environment. In gnome and for fedora 28 exists the problem too.
https://phabricator.kde.org/D15405
Git commit 98c65a438dfb986e59af1ca3f405afba2f680958 by Friedrich W. H. Kossebau. Committed on 17/09/2018 at 09:54. Pushed by kossebau into branch 'master'. [EPS] Fix crash at app shutdown (being tried to persist clipboard image) Summary: Deny any capabilities when there is no QApp instance. Test Plan: Untested, as I do not experience the bug on my system and had no time to invest into trying to. Reviewers: zccrs, dfaure, pino Reviewed By: dfaure Subscribers: kde-frameworks-devel Tags: #frameworks Differential Revision: https://phabricator.kde.org/D15405 M +10 -0 src/imageformats/eps.cpp https://commits.kde.org/kimageformats/98c65a438dfb986e59af1ca3f405afba2f680958
*** Bug 404216 has been marked as a duplicate of this bug. ***