Created attachment 170591 [details] DrKonqi traceback SUMMARY In Firefox 127.0 plasma-browser-integration crashes randomly after upgrading to Plasma 6.0.90. STEPS TO REPRODUCE 1. Open Firefox after Plasma upgrade OBSERVED RESULT Many DrKonqi messages appear that plasma-browser-integration-host has exited unexpectedly. EXPECTED RESULT No crashes SOFTWARE/OS VERSIONS Linux/KDE Plasma: Gentoo Linux 2.15 KDE Plasma Version: 6.0.90 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.1 ADDITIONAL INFORMATION Click on the addon icon in Firefox it says the the native host has exited unexpectedly. Closing the message and clicking the addon icon again, it shows that everything is fine. The issue appears and disappears without any reliable way to reproduce it yet.
Thank you for the bug report! Unfortunately, the backtrace is incomplete and missing debug symbols for the following lines that we need to figure out exactly what's going wrong: Could you please install debug symbols and attach a new symbolicated backtrace generated by using coredumpctl gdb in a terminal window? See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl for details about how to do this. Thanks again!
(In reply to TraceyC from comment #1) > Thank you for the bug report! Unfortunately, the backtrace is incomplete and > missing debug symbols for the following lines that we need to figure out > exactly what's going wrong: > Could you please install debug symbols and attach a new symbolicated > backtrace generated by using coredumpctl gdb in a terminal window? See > https://community.kde.org/Guidelines_and_HOWTOs/Debugging/ > How_to_create_useful_crash_reports#Retrieving_a_backtrace_using_coredumpctl > for details about how to do this. > Thanks again! Thank you! I am not able reproduce the issue on the final Plasma 6.1. It seems to have been fixed. I will reopen the bug in case it happens again.
Glad to hear it's working for you now with 6.1. Thanks for letting us know.
Unfortunately, the issue has reappeared after updating to Plasma 6.1.1. My current configuration now is: Linux/KDE Plasma: Gentoo Linux 2.15 KDE Plasma Version: 6.1.1 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.6-gentoo Graphics Platform: Wayland Browser: Firefox 127.0.2
Created attachment 171169 [details] DrKonqi traceback 2024-06-29 12:04:44
I reported this to openSUSE. Crashing too since updating plasma6-browser-integration (6.1.0 -> 6.1.1) https://bugzilla.opensuse.org/show_bug.cgi?id=1227204 Trace of my crash looks a bit different than the ones attached here so far.
Created attachment 171190 [details] Another traceback for this crash or a similar one with Plasma 6.1.1
Created attachment 171191 [details] Crash in Plasma 6.1.1, openSUSE TW 20240627 (In reply to Alexander Kowalski from comment #7) > Created attachment 171190 [details] > Another traceback for this crash or a similar one with Plasma 6.1.1 And another from Plasma 6.1.1. Looks a bit similar, but maybe I was missing QtCore debug syms.
Haven't seen the crash today, so either yesterday's update to openSUSE Tumbleweed snapshot 20240628 brought something that resolved the issue together with a reboot, or the issue is something that reprocudes sporadically. Monitoring.
(In reply to Lassi Väätämöinen from comment #9) > Haven't seen the crash today, so either yesterday's update to openSUSE > Tumbleweed snapshot 20240628 brought something that resolved the issue > together with a reboot, or the issue is something that reprocudes > sporadically. > > Monitoring. And now after logout+login it started again.
(In reply to Lassi Väätämöinen from comment #10) > And now after logout+login it started again. Oh, probably false alarm, 'coredumpctl list' shows a billion of coredumps from yesterday, and probably the norification was because of those?
(In reply to Alexander Kowalski from comment #7) > Created attachment 171190 [details] > Another traceback for this crash or a similar one with Plasma 6.1.1 Same trace here. Fedora 40 and Plasma 6.1.1, KF6.3.0, Qt6.7.1
*** Bug 489154 has been marked as a duplicate of this bug. ***
Trace from duplicate https://bugs.kde.org/attachment.cgi?id=170940 Arch Linux SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.1.0 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.6.35-2-lts (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 PRO 4750U with Radeon Graphics Memory: 14.9 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: LENOVO Product Name: 20UECTO1WW System Version: ThinkPad T14 Gen 1
*** Bug 490120 has been marked as a duplicate of this bug. ***
I haven't seen this happening for a week now on openSUSE Tumbleweed. SYSTEM INFO Operating System: openSUSE Tumbleweed 20240712 KDE Plasma Version: 6.1.2 KDE Frameworks Version: 6.3.0 Qt Version: 6.7.2 Kernel Version: 6.9.7-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 15,5 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B79 System Version: 4.0
(In reply to Lassi Väätämöinen from comment #16) > I haven't seen this happening for a week now on openSUSE Tumbleweed. Well, two weeks actually.
FWICT it's memory corruption, maybe caused by libtaskmanager or its integration into pbi. Valgrind could help here, but unfortunately it's not quite straightforward to wrap the host executable. Try this: cd $(mktemp -d) cp /usr/bin/plasma-browser-integration-host . cat >pbi-wrap.sh <<EOF #!/bin/sh exec valgrind --log-file="$PWD/vg.log" "$PWD/plasma-browser-integration-host" "\$@" EOF chmod a+x pbi-wrap.sh sed "s#/usr/bin/plasma-browser-integration-host#$PWD/pbi-wrap.sh#" /usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json >json sudo mount --bind json /usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration.json Substitute the correct path for the extension .json for your browser. Then start the browser and somehow reproduce the crash, it should be visible in the temporary directory's vg.log file
(In reply to Fabian Vogt from comment #18) > FWICT it's memory corruption, maybe caused by libtaskmanager or its > integration into pbi. > > Valgrind could help here, but unfortunately it's not quite straightforward > to wrap the host executable. Try this: > > cd $(mktemp -d) > cp /usr/bin/plasma-browser-integration-host . > cat >pbi-wrap.sh <<EOF > #!/bin/sh > exec valgrind --log-file="$PWD/vg.log" > "$PWD/plasma-browser-integration-host" "\$@" > EOF > chmod a+x pbi-wrap.sh > sed "s#/usr/bin/plasma-browser-integration-host#$PWD/pbi-wrap.sh#" > /usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration. > json >json > sudo mount --bind json > /usr/lib64/mozilla/native-messaging-hosts/org.kde.plasma.browser_integration. > json > > Substitute the correct path for the extension .json for your browser. > > Then start the browser and somehow reproduce the crash, it should be visible > in the temporary directory's vg.log file Thanks a lot! Unfortunately, with this wrapper plasma-browser-integration-host always fails to start on my system. This is most likely due to missing support for AVX-512 instructions in valgrind (bug #383010). I will have a look how I can work around this.
Setting back to confirmed
(In reply to TraceyC from comment #20) > Setting back to confirmed Info has not been provided yet.
I've seen this crash too for Firefox 127, but not again during the upgrade to 128 on several machines. Maybe it got somehow fixed?
If anyone is able to reprouce this reliably, please try plasma-browser-integration-host with this line removed: diff --git a/host/settings.cpp b/host/settings.cpp index 6923a1b8..37390043 100644 --- a/host/settings.cpp +++ b/host/settings.cpp @@ -238,7 +238,6 @@ bool Settings::setEnvironmentFromTasksModelIndex(const QModelIndex &idx) qApp->setWindowIcon(QIcon::fromTheme(service->icon())); m_tasksModel->disconnect(this); // prevent further signal emission to not deref a nullptr https://bugs.kde.org/show_bug.cgi?id=435811 - m_tasksModel->deleteLater(); m_tasksModel = nullptr; return true;
(In reply to Fabian Vogt from comment #23) > If anyone is able to reprouce this reliably, please try > plasma-browser-integration-host with this line removed: Your patch seems to have solved the problem for me. Builded with https://aur.archlinux.org/plasma-browser-integration-git.git and the following modifications: diff --git a/PKGBUILD b/PKGBUILD index fb7e900..c37db3c 100644 --- a/PKGBUILD +++ b/PKGBUILD @@ -3,14 +3,14 @@ # Contributor: Antonio Rojas <arojas@archlinux.org> pkgname=plasma-browser-integration-git pkgver=6.0.80_r1569.g57b9b6a3 pkgrel=1 pkgdesc='Components necessary to integrate browsers into the Plasma Desktop' arch=($CARCH) url='https://www.kde.org/plasma-desktop' license=(GPL-2.0-or-later) -depends=(gcc-libs glibc plasma-activities-git kconfig-git kcoreaddons-git kcrash-git kdbusaddons-git kfilemetadata-git ki18n-git kio-git kjobwidgets-git kservice-git kstatusnotifieritem-git plasma-workspace-git purpose-git qt6-base) -makedepends=(git extra-cmake-modules-git) +depends=(gcc-libs glibc plasma-activities kconfig kcoreaddons kcrash kdbusaddons kfilemetadata ki18n kio kjobwidgets kservice kstatusnotifieritem plasma-workspace purpose qt6-base) +makedepends=(git extra-cmake-modules) conflicts=(${pkgname%-git}) provides=(${pkgname%-git}) groups=(plasma-git) @@ -27,6 +27,20 @@ build() { cmake -B build -S ${pkgname%-git} \ -DQT_MAJOR_VERSION=6 \ -DINSTALL_CHROME_MANIFEST=ON + + patch -d $srcdir/${pkgname%-git} -p1 <<EOF +--- a/host/settings.cpp ++++ b/host/settings.cpp +@@ -238,7 +238,6 @@ bool Settings::setEnvironmentFromTasksModelIndex(const QModelIndex &idx) + qApp->setWindowIcon(QIcon::fromTheme(service->icon())); + + m_tasksModel->disconnect(this); // prevent further signal emission to not deref a nullptr https://bugs.kde.org/show_bug.cgi?id=435811 +- m_tasksModel->deleteLater(); + m_tasksModel = nullptr; + + return true; +EOF + cmake --build build } plasma-browser-integration: 6.1.80_r1606.g51427d9a-1 Firefox: 128.0.3-1 Operating System: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2
(In reply to Fabian Vogt from comment #23) > If anyone is able to reprouce this reliably, please try > plasma-browser-integration-host with this line removed: Used as is on my Gentoo, it seems to work as expected, no crashes yet.
Ok, that basically confirms it's somehow caused by the WaylandTasksModel. Question is how. Could you please try the valgrind method from comment 18?
Created attachment 172173 [details] Backtrace 1st August 2024 Started crashing again today. Operating System: openSUSE Tumbleweed 20240730 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 Kernel Version: 6.10.2-1-default (64-bit) Graphics Platform: Wayland Processors: 12 × AMD Ryzen 5 3600 6-Core Processor Memory: 31,3 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series Manufacturer: Micro-Star International Co., Ltd. Product Name: MS-7B79 System Version: 4.0
(In reply to Fabian Vogt from comment #18) > FWICT it's memory corruption, maybe caused by libtaskmanager or its > integration into pbi. > > Valgrind could help here, but unfortunately it's not quite straightforward > to wrap the host executable. Try this: > ..... Tried it, but the issue did not reproduce after Firefox restart... of course. Not sure if this is of any relevance, I saw the first crash when I had issues with Nextcloud sync in the Nextcloud desktop app.
(In reply to Lassi Väätämöinen from comment #28) > Tried it, but the issue did not reproduce after Firefox restart... of course. > > Not sure if this is of any relevance, I saw the first crash when I had > issues with Nextcloud sync in the Nextcloud desktop app. Now not happening anymore since 15:00 today. Got 306 coredumps before that, but not reproduced during Valgrind debugging.
(In reply to Lassi Väätämöinen from comment #29) > (In reply to Lassi Väätämöinen from comment #28) > > > Tried it, but the issue did not reproduce after Firefox restart... of course. > > > > Not sure if this is of any relevance, I saw the first crash when I had > > issues with Nextcloud sync in the Nextcloud desktop app. > > > Now not happening anymore since 15:00 today. > Got 306 coredumps before that, but not reproduced during Valgrind debugging. That actually confirms even more that it's cause by the waylandtasksmodel, as that is by default not accessible when using valgrind due to kwin access controls. To disable those, kwin_wayland needs to be started with KWIN_WAYLAND_NO_PERMISSION_CHECKS=1. You can add that to /etc/environment or cat <<EOF >/run/user/1000/systemd/user/plasma-kwin_wayland.service.d/override.conf [Service] Environment=KWIN_WAYLAND_NO_PERMISSION_CHECKS=1 EOF and log out and in again.
Created attachment 172466 [details] vg.log (with no core dumped) on Plasma 6.1.4 openSUSE TW I've followed your instructions for Valgrind. Though unfortunately I could not reproduce a crash resulting in a core dumped, I can at least report some memory allocation issues, which are maybe worth fixing too. :)
(In reply to postix from comment #31) > Created attachment 172466 [details] > vg.log (with no core dumped) on Plasma 6.1.4 openSUSE TW > > I've followed your instructions for Valgrind. Though unfortunately I could > not reproduce a crash resulting in a core dumped, I can at least report some > memory allocation issues, which are maybe worth fixing too. :) Those are probably false positivies. Hardware accelerated functions like aeshash intentionally read beyond buffer boundaries for better alignment. Did you follow comment 30 as well? Otherwise you likely won't get a crash ever when running it with valgrind.
(In reply to Fabian Vogt from comment #32) > Did you follow comment 30 as well? Otherwise you likely won't get a crash > ever when running it with valgrind. Yes, already a few days ago, but it seems like the file got purged during the last `zypper dup`.
(In reply to postix from comment #33) > (In reply to Fabian Vogt from comment #32) > > Did you follow comment 30 as well? Otherwise you likely won't get a crash > > ever when running it with valgrind. > > Yes, already a few days ago, but it seems like the file got purged during > the last `zypper dup`. Files in $XDG_RUNTIME_DIR only exist until logout (+ some grace time).
🐛🧹 ⚠️ This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information, then set the bug status to REPORTED. If there is no change for at least 30 days, it will be automatically closed as RESOLVED WORKSFORME. For more information about our bug triaging procedures, please read https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging. Thank you for helping us make KDE software even better for everyone!
(In reply to Fabian Vogt from comment #30) > (In reply to Lassi Väätämöinen from comment #29) > > (In reply to Lassi Väätämöinen from comment #28) > > > > > Tried it, but the issue did not reproduce after Firefox restart... of course. > > > > > > Not sure if this is of any relevance, I saw the first crash when I had > > > issues with Nextcloud sync in the Nextcloud desktop app. > > > > > > Now not happening anymore since 15:00 today. > > Got 306 coredumps before that, but not reproduced during Valgrind debugging. > > That actually confirms even more that it's cause by the waylandtasksmodel, > as that is by default not accessible when using valgrind due to kwin access > controls. To disable those, kwin_wayland needs to be started with > KWIN_WAYLAND_NO_PERMISSION_CHECKS=1. > You can add that to /etc/environment or > > cat <<EOF > >/run/user/1000/systemd/user/plasma-kwin_wayland.service.d/override.conf > [Service] > Environment=KWIN_WAYLAND_NO_PERMISSION_CHECKS=1 > EOF > > and log out and in again. Is it possible that there are other interfering factors? I tried running it under valgrind with the environment variable set for kwin_wayland but it still won't crash like that while relatively consistently crashing otherwise.
(In reply to Alexander Kowalski from comment #36) > (In reply to Fabian Vogt from comment #30) > > (In reply to Lassi Väätämöinen from comment #29) > > > (In reply to Lassi Väätämöinen from comment #28) > > > > > > > Tried it, but the issue did not reproduce after Firefox restart... of course. > > > > > > > > Not sure if this is of any relevance, I saw the first crash when I had > > > > issues with Nextcloud sync in the Nextcloud desktop app. > > > > > > > > > Now not happening anymore since 15:00 today. > > > Got 306 coredumps before that, but not reproduced during Valgrind debugging. > > > > That actually confirms even more that it's cause by the waylandtasksmodel, > > as that is by default not accessible when using valgrind due to kwin access > > controls. To disable those, kwin_wayland needs to be started with > > KWIN_WAYLAND_NO_PERMISSION_CHECKS=1. > > You can add that to /etc/environment or > > > > cat <<EOF > > >/run/user/1000/systemd/user/plasma-kwin_wayland.service.d/override.conf > > [Service] > > Environment=KWIN_WAYLAND_NO_PERMISSION_CHECKS=1 > > EOF > > > > and log out and in again. > > Is it possible that there are other interfering factors? I tried running it > under valgrind with the environment variable set for kwin_wayland but it > still won't crash like that while relatively consistently crashing otherwise. It's possible, but I can't think of any.
Created attachment 173198 [details] New distinct possibly related backtrace I have a new backtrace that looks different from the previous ones and seems like it could be related. For some reason the date and time written into the file name is two days ago although I opened it from a notification I got about an hour ago, so if that time is correct I have no idea if anything specific happened at the same time. (When I got the notification, Firefox was not even running or starting, I was just updating packages.)
Created attachment 173213 [details] AddressSanitizer error message I recompiled plasma-workspace and plasma-browser-integration with debug information and sanitizers enabled and was able to get this error message for a heap-use-after-free.
(In reply to Alexander Kowalski from comment #39) > Created attachment 173213 [details] > AddressSanitizer error message > > I recompiled plasma-workspace and plasma-browser-integration with debug > information and sanitizers enabled and was able to get this error message > for a heap-use-after-free. https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4586 might fix this, can you try with that applied?
Created attachment 173651 [details] AddressSanitizer error message (In reply to Fabian Vogt from comment #40) > (In reply to Alexander Kowalski from comment #39) > > Created attachment 173213 [details] > > AddressSanitizer error message > > > > I recompiled plasma-workspace and plasma-browser-integration with debug > > information and sanitizers enabled and was able to get this error message > > for a heap-use-after-free. > > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4586 might > fix this, can you try with that applied? Unfortunately the only difference I see is that the line numbers have shifted a little bit due to application of the merge request.
(In reply to Alexander Kowalski from comment #41) > Created attachment 173651 [details] > AddressSanitizer error message > > (In reply to Fabian Vogt from comment #40) > > (In reply to Alexander Kowalski from comment #39) > > > Created attachment 173213 [details] > > > AddressSanitizer error message > > > > > > I recompiled plasma-workspace and plasma-browser-integration with debug > > > information and sanitizers enabled and was able to get this error message > > > for a heap-use-after-free. > > > > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4586 might > > fix this, can you try with that applied? > > Unfortunately the only difference I see is that the line numbers have > shifted a little bit due to application of the merge request. Meh. Ok, so needs a closer look.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4697
(In reply to Bug Janitor Service from comment #43) > A possibly relevant merge request was started @ > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4697 Can you try ^?
(In reply to Fabian Vogt from comment #44) > (In reply to Bug Janitor Service from comment #43) > > A possibly relevant merge request was started @ > > https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/4697 > > Can you try ^? No errors with sanitizers and no crashes with 'standard' build options either so far. For all I can tell as someone with no experience with this codebase at all going just by what I have seen so far it also seems like a reasonable solution for at least this bug. If something does come up after all I will report back, but I hope that won't be necessary.
Git commit 561646763d994288d771b0efaa9b2a3e45e810fa by Méven Car. Committed on 15/09/2024 at 06:46. Pushed by meven into branch 'master'. libtaskmanager/waylandtasksmodel: disconnect from parentWindowChanged in dtor As windows destruction might happen in any order, destruction of parent window of of transient ones will trigger their parentWindowChanged event. M +6 -1 libtaskmanager/waylandtasksmodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/561646763d994288d771b0efaa9b2a3e45e810fa
Git commit 5751ca2b246b1d43886da13a57539df43793ac8f by Méven Car. Committed on 15/09/2024 at 11:33. Pushed by meven into branch 'Plasma/6.2'. libtaskmanager/waylandtasksmodel: disconnect from parentWindowChanged in dtor As windows destruction might happen in any order, destruction of parent window of of transient ones will trigger their parentWindowChanged event. (cherry picked from commit 561646763d994288d771b0efaa9b2a3e45e810fa) M +6 -1 libtaskmanager/waylandtasksmodel.cpp https://invent.kde.org/plasma/plasma-workspace/-/commit/5751ca2b246b1d43886da13a57539df43793ac8f
*** Bug 492617 has been marked as a duplicate of this bug. ***
*** Bug 493321 has been marked as a duplicate of this bug. ***