https://bugs.kde.org/show_bug.cgi?id=397040

--- Comment #6 from zccrs <zc...@live.com> ---
(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.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to