| Summary: | kscreenlocker_greet crashed in ScreenLocker::UnlockApp::createViewForScreen() | ||
|---|---|---|---|
| Product: | [Unmaintained] kscreenlocker | Reporter: | Matt Fagnani <matt.fagnani> |
| Component: | greeter | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | RESOLVED DOWNSTREAM | ||
| Severity: | crash | CC: | bshah, hgblob, jr, kde, nate |
| Priority: | NOR | ||
| Version First Reported In: | 5.26.2 | ||
| Target Milestone: | --- | ||
| Platform: | Fedora RPMs | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
| Attachments: | valgrind log for kscreenlocker_greeter --testing crash | ||
|
Description
Matt Fagnani
2022-11-02 17:37:45 UTC
Possible issue where it thinks it has no screens and tried to create a view for a null screen?
Specifically, it's dying in createViewForScreen() when it gets to markViewsAsVisible():
auto onFrameSwapped = [this, view] {
markViewsAsVisible(view);
};
Created attachment 153422 [details]
valgrind log for kscreenlocker_greeter --testing crash
Your interpretation agrees with lines like kscreenlocker_greet[2312]: qt.qpa.wayland: Creating a fake screen in order for Qt not to crash in the journal and QtWayland::wl_surface::object having this=0x10. I ran valgrind --log-file=valgrind-kscreenlocker_greet-1.txt --enable-debuginfod=no /usr/libexec/kscreenlocker_greet --testing in a VM like the one I described. Nine invalid reads of 16 bytes were shown in the valgrind log which were less than 16 bytes from the end of the buffers, and so they might've been overreads. The first such invalid read was
==3353== Invalid read of size 16
==3353== at 0x2B3566D8: ???
==3353== by 0x2B222C6B: ???
==3353== Address 0x2b223c6e is 46,222 bytes inside a block of size 46,228 alloc'd
==3353== at 0x484186F: malloc (vg_replace_malloc.c:393)
==3353== by 0x6330581: QArrayData::allocate(unsigned long, unsigned long, unsigned long, QFlags<QArrayData::AllocationOption>) (qarraydata.cpp:218)
==3353== by 0x63B225D: allocate (qarraydata.h:225)
==3353== by 0x63B225D: QString::fromLatin1_helper(char const*, int) (qstring.cpp:5464)
==3353== by 0x263DF999: UnknownInlinedFun (qstring.h:701)
==3353== by 0x263DF999: UnknownInlinedFun (qstring.h:713)
==3353== by 0x263DF999: Plasma::SharedSvgRenderer::load(QByteArray const&, QString const&, QHash<QString, QRectF>&) [clone .isra.0] (svg.cpp:134)
==3353== by 0x263CD0B3: UnknownInlinedFun (svg.cpp:81)
==3353== by 0x263CD0B3: Plasma::SvgPrivate::createRenderer() [clone .part.0] (svg.cpp:681)
==3353== by 0x263BE617: UnknownInlinedFun (qbasicatomic.h:118)
==3353== by 0x263BE617: UnknownInlinedFun (svg.cpp:756)
==3353== by 0x263BE617: Plasma::SvgPrivate::elementRect(QString const&) (svg.cpp:745)
==3353== by 0x263BE8ED: Plasma::Svg::hasElement(QString const&) const (svg.cpp:1074)
==3353== by 0x2659B6AC: UnknownInlinedFun (iconitem.cpp:169)
==3353== by 0x2659B6AC: IconItem::setSource(QVariant const&) (iconitem.cpp:370)
==3353== by 0x2658971A: IconItem::qt_metacall(QMetaObject::Call, int, void**) (moc_iconitem.cpp:385)
==3353== by 0x582CCD4: QQmlVMEMetaObject::metaCall(QObject*, QMetaObject::Call, int, void**) (in /usr/lib64/libQt5Qml.so.5.15.7)
==3353== by 0x58B5DDD: ??? (in /usr/lib64/libQt5Qml.so.5.15.7)
==3353== by 0x58B8362: QQmlObjectCreator::setPropertyValue(QQmlPropertyData const*, QV4::CompiledData::Binding const*) (in /usr/lib64/libQt5Qml.so.5.15.7)
==3353==
The traces where the invalid reads happened all had ??? instead of the functions and lines so they're harder to interpret. Some Conditional jump or move depends on uninitialised value(s) lines were shown. Then there was an invalid read of 8 bytes at 0x18 in UnknownInlinedFun (qwayland-wayland.h:637) with a trace like I reported resulting in the segmentation fault.
==3353== Invalid read of size 8
==3353== at 0x4ACEDA6: UnknownInlinedFun (qwayland-wayland.h:637)
==3353== by 0x4ACEDA6: LayerShellQt::QWaylandLayerSurface::QWaylandLayerSurface(LayerShellQt::QWaylandLayerShell*, QtWaylandClient::QWaylandWindow*) (qwaylandlayersurface.cpp:38)
==3353== by 0x4ACF5B8: LayerShellQt::QWaylandLayerShell::createLayerSurface(QtWaylandClient::QWaylandWindow*) (qwaylandlayershell.cpp:26)
==3353== by 0x6C7D514: QtWaylandClient::QWaylandWindow::initWindow() (qwaylandwindow.cpp:141)
==3353== by 0x6C7D84C: UnknownInlinedFun (qwaylandwindow.cpp:436)
==3353== by 0x6C7D84C: .LTHUNK9.lto_priv.0 (qwaylandwindow.cpp:428)
==3353== by 0x5D76096: QWindowPrivate::setVisible(bool) (in /usr/lib64/libQt5Gui.so.5.15.7)
==3353== by 0x11F7BE: ScreenLocker::UnlockApp::createViewForScreen(QScreen*) (greeterapp.cpp:417)
==3353== by 0x11FF33: ScreenLocker::UnlockApp::handleScreen(QScreen*) (greeterapp.cpp:306)
==3353== by 0x116DDF: UnknownInlinedFun (greeterapp.cpp:296)
==3353== by 0x116DDF: main (main.cpp:187)
==3353== Address 0x18 is not stack'd, malloc'd or (recently) free'd
==3353==
==3353==
==3353== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==3353== Access not within mapped region at address 0x18
==3353== at 0x4ACEDA6: UnknownInlinedFun (qwayland-wayland.h:637)
==3353== by 0x4ACEDA6: LayerShellQt::QWaylandLayerSurface::QWaylandLayerSurface(LayerShellQt::QWaylandLayerShell*, QtWaylandClient::QWaylandWindow*) (qwaylandlayersurface.cpp:38)
==3353== by 0x4ACF5B8: LayerShellQt::QWaylandLayerShell::createLayerSurface(QtWaylandClient::QWaylandWindow*) (qwaylandlayershell.cpp:26)
==3353== by 0x6C7D514: QtWaylandClient::QWaylandWindow::initWindow() (qwaylandwindow.cpp:141)
==3353== by 0x6C7D84C: UnknownInlinedFun (qwaylandwindow.cpp:436)
==3353== by 0x6C7D84C: .LTHUNK9.lto_priv.0 (qwaylandwindow.cpp:428)
==3353== by 0x5D76096: QWindowPrivate::setVisible(bool) (in /usr/lib64/libQt5Gui.so.5.15.7)
==3353== by 0x11F7BE: ScreenLocker::UnlockApp::createViewForScreen(QScreen*) (greeterapp.cpp:417)
==3353== by 0x11FF33: ScreenLocker::UnlockApp::handleScreen(QScreen*) (greeterapp.cpp:306)
==3353== by 0x116DDF: UnknownInlinedFun (greeterapp.cpp:296)
==3353== by 0x116DDF: main (main.cpp:187)
I'm attached the full valgrind log.
My Fedora 37 KDE Plasma installation and Fedora-KDE-Live-x86_64-Rawhide-20221029.n.0.iso don't seem to be affected by this problem; they have Plasma 5.26.2, KF 5.99.0, and Qt 5.15.6. The problem might've been introduced in Qt 5.15.7. layer-shell-qt-5.26.2-1.fc38 needed to be rebuilt with Qt 5.15.7 since it used the private Qt API, and not doing so resulted in sddm crashes reported at https://bugzilla.redhat.com/show_bug.cgi?id=2139465 I found the sddm crashes with Fedora-KDE-Live-x86_64-Rawhide-20221102.n.0.iso had similar functions at the tops of their stacks like LayerShellQt::QWaylandLayerSurface::QWaylandLayerSurface to the kscreenlocker_greet crashes I reported. kscreenlocker_greet didn't crash in VMs with Fedora-KDE-Live-x86_64-Rawhide-20221103.n.0.iso https://koji.fedoraproject.org/koji/buildinfo?buildID=2083580 which contained the layer-shell-qt-5.26.2-2.fc38 rebuild with Qt 5.15.7 https://koji.fedoraproject.org/koji/buildinfo?buildID=2083363 I'm seeing the same crash on Neon 20.04 after updating to plasma 5.26 on two different computers. Should I report the bug again for neon or reopen this one? Can you upgrade to Neon 22.04 and try again? If you are, it might be a Neon packaging bug, like Matt's issue was a Fedora packaging bug. In that case, a new bug report for the Neon folks would be appropriate. Can't upgrade to 22.04 at the moment, too big disruption but as Matt suggested I recompiled layer-shell-qt with the latest qt version and the greeter started working again. So for sure neon has the same issue as Fedora. |