https://bugs.kde.org/show_bug.cgi?id=517353
Ahmet Kaan Demirci <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #12 from Ahmet Kaan Demirci <[email protected]> --- Confirming this on Qt 6.11.0 (Arch Linux, packages upgraded 2026-05-11): - drkonqi 6.6.4-1 - knotifications 6.26.0-1 - qt6-base 6.11.0-4 Reproduces 100% with any coredump -- "bash -c 'kill -SEGV $$'" is enough. Each launcher instance crashes within ~0.5s, and because the launcher's own crash generates another coredump, the loop is self-sustaining at ~3 crashes/sec until the units are masked. ~17 launcher coredumps per single user-app crash before intervention. Confirming the QTBUG-146017 cross-reference ------------------------------------------- The upstream Qt bug QTBUG-146017 ("QTextDocumentFragment::fromHtml(\"<tt/>\") segfaults immediately") was closed Fixed on 2026-05-05 with commit 515cbbacf in qt/qtbase dev, fix version 6.12.0. Patch: https://codereview.qt-project.org/c/qt/qtbase/+/732021 The real Qt-side stack (from QTBUG-146017) is: qAbort qt_maybe_message_fatal<QString&> qt_message QMessageLogger::fatal qt_assert QList<QString>::constFirst <- assert: constFirst on empty QList standardDeclarationForNode QTextHtmlParser::declarationsForNode QTextHtmlParser::parseTag QTextHtmlParser::parse QTextHtmlImporter::QTextHtmlImporter QTextDocumentFragment::fromHtml Per Eskil Abrahamsen Blomfeldt on QTBUG-146017: "any application using GUI classes without a QGuiApplication will eventually crash." In Qt 6.11, QTextHtmlParser looks up the default font family via QList::constFirst() on an empty list when no QGuiApplication is initialized -> assertion failure -> abort (kernel reports it as SIGSEGV via the abort path). Why drkonqi-coredump-launcher specifically ------------------------------------------ Looking at the launcher's stack, frame 18 is QCoreApplication::exec() -- the launcher is QCoreApplication-only, not QGuiApplication. When KNotificationPlugin::stripRichText calls QTextDocumentFragment::fromHtml() to render the notification body, Qt 6.11's stricter assert fires because there is no QGuiApplication to provide font defaults. My local stack (symbolicated via debuginfod.archlinux.org; stripped binary so non-exported frames resolve to nearest preceding symbol): #0 QVariant::QVariant(QString const&)* libQt6Core.so.6 + 0x205b63 #1-2 [Qt HTML helpers] libQt6Gui.so.6 + 0x571989, 0x50e4d4 #3 QTextDocumentFragment::fromHtml(...) libQt6Gui.so.6 + 0x51728c #4-6 [KNotifications, near KNotifyConfig::readPathEntry] libKF6Notifications.so.6 + 0x2303e, 0x23b57, 0x2d7eb #7 Qt event handler libQt6Core.so.6 + 0x1ecb9b #8 QDBusPendingCallWatcher::finished libQt6DBus.so.6 + 0x950c1 #9 QObject::event(QEvent*) #10 QCoreApplication::notifyInternal2(...) #11 QCoreApplicationPrivate::sendPostedEvents(...) ... #18 QCoreApplication::exec() #19 drkonqi-coredump-launcher main loop * Frame #0 reports QVariant::QVariant(QString) only because the binary is stripped -- addr2line resolves the offset to the nearest preceding exported symbol. The actual code at +0x205b63 is almost certainly on the qt_assert/qAbort path shown in QTBUG-146017's trace. Suggested KDE-side workaround for 6.11 users -------------------------------------------- The Qt fix is in 6.12.0, but distros on Qt 6.11 will need this for months. Two options at the KDE layer: 1. Make drkonqi-coredump-launcher a QGuiApplication instead of QCoreApplication. This satisfies Qt 6.11's font-lookup precondition. Adds a GUI dependency to a service that already needs Qt anyway, so minimal cost. 2. In KNotificationPlugin::stripRichText, skip QTextDocumentFragment ::fromHtml when QGuiApplication::instance() == nullptr and fall back to a regex-based tag strip. Defense-in-depth and benefits any other QCoreApplication consumer of KNotifications. Either fix unblocks Qt 6.11 users without waiting for Qt 6.12 to ship in distros. Environment ----------- - Arch Linux, kernel 6.18.29-1-lts - Session: Hyprland 0.55.0 (Wayland) - Notification daemon: hyprpanel (gjs/ags) -- but this is incidental; the crash happens during notification construction, before any IPC with the daemon, so it should reproduce under any notification daemon (including Plasma's) when triggered by a coredump from a non-QGuiApplication binary. Supporting logs attached (verbose journal entry for one launcher crash, journal excerpt showing the loop topology, full environment dump). Workaround in the meantime -------------------------- systemctl --user mask [email protected] \ drkonqi-coredump-launcher.socket \ drkonqi-coredump-pickup.service -- You are receiving this mail because: You are watching all bug changes.
