The plugin can cause an abort if the application uses a QCoreApplication
paul-h opened this issue · comments
Summary
The PFBImage plugin can cause an abort to happen in Qt if an application is used that creates a QCoreApplication at startup rather than a QGuiApplication or QApplication and the application calls some Qt functions that cause this plugin to be created for example QImage::save().
This is the specific abort
QFontDatabase: Must construct a QGuiApplication before accessing QFontDatabase
Details
This came to light when we received reports that some Fedora 31 users were seeing a crash of one of our utils (mythpreviewgen) that creates a thumbnail image from a video file. It is a command line utility so as per the Qt guidelines it uses QCoreApplication at startup which then goes on to crash with the abort when your plugin is created when we go to save the thumb image with QImage::save().
It looks like all Fedora 31 and possibly 32 get your plugin installed when they blanket install everything whether they need it or not using dnf -y install qt5*
To be clear our util doesn't use or require the PBFImage plugin it gets created automatically by Qt when it loads the list of available QImageReaders.
The affected users can prevent the crash by uninstalling the plugin with
dnf -y remove qt5-qtpbfimageformat
Possible Fix
It would be nice if when asked to create an instance of the plugin it looked to see if the application is using a QCoreApplication and either refuse to be created or changes it's behaviour to avoid the abort.
Upstream Forum Post
For reference the forum post where this problem was first reported is here
Mythpreviewgen Not Happy
This is a bug of mythpreviewgen, not QtPBFImagePlugin as any application using stuff from the Qt GUI API (QImage is part of the GUI module) is required to use at least QGuiApplication (or QApplication).
Apart from being stated in the documentation it was also affirmed in the Qt mailing list recently.
A quick follow up for anyone who should come across this problem in the future.
If the option is open to you the easiest and undoubtedly the proper fix is to just use QGuiApplication in your application.
If you can't do that you are stuffed the only fix is to un-install this plugin and the problem will go away.
My personal view is a 3rd party Qt plugin should not be knowingly crashing applications, even if they are not following the guide lines, sometimes programmers do bend the rules slightly :)
There is a simple 3 line patch that will allow the plugin to fail gracefully rather than throwing an abort and crashing the application which in my view is a more friendly thing to do but sadly that is not a view held by tunic0 :( .
It is not the plugin that is "crashing" (it's not even a crash) the application but an assert in Qt that detects someone is using the GUI API without a proper GUI module initialisation (using the QGuiApplication instance). Qt has however such asserts not on all GUI API use cases so QtPBFImagePlugin may be the first or even the only code that will trigger the assert.
All this means, that when your application is broken and uses the wrong base class, ANY Qt plugin or even Qt itself may trigger such assert at ANY time. So the solution is really not to request every Qt plugin or Qt self to include code like:
if (used_from_a_broken_app_like_mythpreviewgen)
do_nothing_and_return_NULL
in front of every GUI API call (or at least in the initialisation in case of a module). The only solution is to fix your code, since otherwise you do not know who and when will trigger such an assert the next time (It may be another plugin or even a new Qt version).