Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 2144200 - QtWebEngine crashes Plasma Desktop on ARM Macs
Summary: QtWebEngine crashes Plasma Desktop on ARM Macs
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: qt5-qtwebengine
Version: 37
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Neal Gompa
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-11-19 21:17 UTC by Neal Gompa
Modified: 2022-11-27 12:51 UTC (History)
13 users (show)

Fixed In Version: qt5-qtwebengine-5.15.10-4.fc37
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-11-22 01:36:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
Screenshot of the crash backtrace in the systemd journal (deleted)
2022-11-19 21:17 UTC, Neal Gompa
no flags Details
Full backtrace from GDB (deleted)
2022-11-19 21:45 UTC, Neal Gompa
no flags Details
plasmashell core dump (deleted)
2022-11-19 21:51 UTC, Neal Gompa
no flags Details
Screenshot showing a working KDE Plasma Desktop (deleted)
2022-11-20 18:09 UTC, Neal Gompa
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Qt Bug Tracker QTBUG-108674 0 Not Evaluated Reported QtWebEngine crashes on Fedora Linux on ARM Macs 2022-11-19 21:18:13 UTC

Description Neal Gompa 2022-11-19 21:17:57 UTC
Created attachment 1925742 [details]
Screenshot of the crash backtrace in the systemd journal

Description of problem:
When trying to run KDE Plasma on Fedora Linux 37 on ARM Macs, Plasma Shell crashes showing a backtrace in Qt5PDF (which is part of QtWebEngine).

I'm not sure what's going on here per se, but I am reasonably confident it may have to do with older versions of Chromium not supporting 16KB page sizes properly.

As a point of comparison, Chromium 105 packaged in Fedora is able to startup and function.

Version-Release number of selected component (if applicable):
5.15.10-3.fc37

How reproducible:
Always

Steps to Reproduce:
1. Install the Fedora Workstation 37 Asahi image on an ARM Mac 
2. Install KDE Plasma
3. Try to switch to the KDE Plasma desktop

Actual results:
A black screen of emptiness awaits you, with "plasmashell" crashing in the background due to QtWebEngine.

Expected results:
KDE Plasma Desktop boots up.

Additional info:
Upstream Chromium fixed this with this change set: https://chromium-review.googlesource.com/c/chromium/src/+/3545665

Comment 1 Neal Gompa 2022-11-19 21:45:10 UTC
Created attachment 1925754 [details]
Full backtrace from GDB

Here's the full backtrace from GDB

Comment 2 Neal Gompa 2022-11-19 21:51:01 UTC
Created attachment 1925755 [details]
plasmashell core dump

systemd core dump for plasmashell

Comment 3 Neal Gompa 2022-11-20 13:26:47 UTC
Pull request to fix this: https://src.fedoraproject.org/rpms/qt5-qtwebengine/pull-request/13

Copr build to test fix: https://copr.fedorainfracloud.org/coprs/build/5048782

Comment 4 Kevin Kofler 2022-11-20 15:50:01 UTC
Have you already tested this? Does it work? I am asking because I doubt it does, as is, because the patch does not modify pdfium at all, whereas the crash was in pdfium::base::SetSystemPagesAccess. My guess would be that the changes in the patch are needed, too, but you are missing some change to pdfium that fixes the crash you ran into.

Comment 5 Neal Gompa 2022-11-20 15:51:14 UTC
I have not tested it yet. I'm building in COPR right now so I can test it.

Comment 6 Kevin Kofler 2022-11-20 16:03:08 UTC
Another question is, why does Plasma Desktop load libQt5Pdf.so.5 to show a wallpaper? Is that using a PDF as the wallpaper? Surely that is not the common case, is it?

Comment 7 Kevin Kofler 2022-11-20 16:11:21 UTC
But it looks like pdfium::base is actually the same code as chromium::base, just in a different namespace for some reason. The code seems to be from the Chromium code base (base/allocator/partition_allocator/page_allocator.cc), not the Pdfium code base. So the patch could be sufficient after all. So I am eagerly waiting for your test results.

Comment 8 Neal Gompa 2022-11-20 18:03:28 UTC
So I did a local build (which built *really quickly*) and I have verified that the Plasma Desktop now works with this fix.

Comment 9 Neal Gompa 2022-11-20 18:09:12 UTC
Created attachment 1925970 [details]
Screenshot showing a working KDE Plasma Desktop

With the fixed QtWebEngine, I was able to load Plasma Desktop and take a screenshot.

Comment 10 Kevin Kofler 2022-11-20 18:39:06 UTC
Cool!

The one question that is still open though is the one I asked in comment 6: Why does Plasma Desktop load libQt5Pdf.so.5 to show a wallpaper? Are you using a PDF as the wallpaper? Or why does it think the wallpaper is a PDF?

Comment 11 Neal Gompa 2022-11-20 18:41:14 UTC
(In reply to Kevin Kofler from comment #10)
> Cool!
> 
> The one question that is still open though is the one I asked in comment 6:
> Why does Plasma Desktop load libQt5Pdf.so.5 to show a wallpaper? Are you
> using a PDF as the wallpaper? Or why does it think the wallpaper is a PDF?

I'm not using a PDF as a wallpaper. so I don't know.

Comment 12 Kevin Kofler 2022-11-20 18:46:44 UTC
Looks like something that should be addressed separately upstream. Though QtWebEngine would have needed to be fixed anyway. So thanks for the fix!

Comment 13 Neal Gompa 2022-11-20 19:17:26 UTC
(In reply to Kevin Kofler from comment #12)
> Looks like something that should be addressed separately upstream. Though
> QtWebEngine would have needed to be fixed anyway. So thanks for the fix!

I'm building it now for F37 and Rawhide...

Rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=2090854
Fedora 37: https://koji.fedoraproject.org/koji/buildinfo?buildID=2090853

Comment 14 Fedora Update System 2022-11-21 00:10:49 UTC
FEDORA-2022-af3ef0a1b6 has been submitted as an update to Fedora 37. https://bodhi.fedoraproject.org/updates/FEDORA-2022-af3ef0a1b6

Comment 15 Fedora Update System 2022-11-21 02:12:53 UTC
FEDORA-2022-af3ef0a1b6 has been pushed to the Fedora 37 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2022-af3ef0a1b6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-af3ef0a1b6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 16 Fedora Update System 2022-11-22 01:36:37 UTC
FEDORA-2022-af3ef0a1b6 has been pushed to the Fedora 37 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 17 Neal Gompa 2022-11-26 01:50:15 UTC
FYI, upstream Gerrit review for the fix: https://codereview.qt-project.org/c/qt/qtwebengine-chromium/+/445075

Comment 18 Kevin Kofler 2022-11-27 02:11:02 UTC
So what I think is happening here is that the code to autodetect the file type of the wallpaper (MediaProxy::determineBackgroundType) works by enumerating all types supported by QMovie (QMovie::supportedFormats) and then checking whether they match. But QMovie decides that it supports all formats supported by QImage that support QImageIOHandler::Animation, and to check that property, it needs to initialize the QImage decoder. As a result, this ends up initializing any and all installed QImage decoder plugins. There is also one for PDF, because somebody thought it would be a great idea to treat a PDF like an image rather than a document. (I think PDF wallpapers were actually one of the intended use cases.) So then we end up calling into QPdfPlugin::create, which initializes pdfium, and if that fails to initialize, the whole Plasma crashes and we lose.

I am not sure where the best place to fix this mess would be, but initializing all image decoding libraries in existence (some of which can have quite poor quality) in a process (all the more in the desktop shell's main process) strikes me as a very bad idea.

Comment 19 Kevin Kofler 2022-11-27 02:13:48 UTC
I wonder whether using QImageReader::supportedImageFormats() instead of QMovie::supportedFormats() would be sufficient to avoid having to initialize all the plugins or whether that would also initialize them all.

Comment 20 Neal Gompa 2022-11-27 11:12:58 UTC
But animated backgrounds and video backgrounds are also supported in Plasma, so switching to QImageReader::supportedImageFormats() would remove that ability, wouldn't it?

Comment 21 Kevin Kofler 2022-11-27 12:19:26 UTC
Not necessarily, since QImageReader::supportedImageFormats() is (or should be, at least) a superset of QMovie::supportedFormats(). By the way, I wonder through what code path image formats that do not support animations are going, because they are not (or at least should not be) returned by QMovie::supportedFormats(). I guess I need to look at the MediaProxy::determineBackgroundType code.

Comment 22 Kevin Kofler 2022-11-27 12:30:02 UTC
So this is the code:
https://invent.kde.org/plasma/plasma-workspace/-/blob/42a88bfdd4a5a71cc608230240f1877f7840de44/wallpapers/image/plugin/utils/mediaproxy.cpp#L250

What this actually does is, it checks whether the image format that corresponds to the file extension supports animations. It does so by enumerating all formats that support animations, which is a very inefficient way to do the check. In addition, it also does not check anywhere whether the image is actually animated. It just assumes that, if the image format supports animations, we have a BackgroundType::Type::AnimatedImage.

The better way would be to do what QMovie::supportedFormats() does internally, but only on the type we actually care about, without enumerating them:
    QBuffer dummyBuffer;
    dummyBuffer.open(QIODevice::ReadOnly);

    if (QImageReader(&buffer, QFileInfo(filePath).suffix().toLower().toLatin1()).supportsOption(QImageIOHandler::Animation)) {
        // Derived from the suffix
        m_backgroundType = BackgroundType::Type::AnimatedImage;
…

Comment 23 Kevin Kofler 2022-11-27 12:31:00 UTC
(That still only checks the file type, not the actual image, but it does so while instantiating only the one image reader that we care about, not every single one.)

Comment 24 Kevin Kofler 2022-11-27 12:32:25 UTC
Sorry, typo fix (I renamed buffer to dummyBuffer to be clear, but forgot to rename one usage instance of it):
    QBuffer dummyBuffer;
    dummyBuffer.open(QIODevice::ReadOnly);

    if (QImageReader(&dummyBuffer, QFileInfo(filePath).suffix().toLower().toLatin1()).supportsOption(QImageIOHandler::Animation)) {
        // Derived from the suffix
        m_backgroundType = BackgroundType::Type::AnimatedImage;

(Editing messages is a feature sorely missing in Bugzilla.)

Comment 25 Kevin Kofler 2022-11-27 12:51:11 UTC
I have filed https://bugs.kde.org/show_bug.cgi?id=462308 for that issue (MediaProxy::determineBackgroundType needlessly instantiates all available QImage reader plugins).


Note You need to log in before you can comment on or make changes to this bug.