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.
