Closed Bluey26 closed 2 months ago
It seems something in Arch has caused strange problems (also see https://github.com/lxqt/lxqt-panel/issues/2044; do you use KWin too?). When did it start to happen? After an Arch upgrade?
Maybe this is related to the dbus-broker change made in Archlinux in January 9th?
Unlikely. I have it here, in Manjaro, and have encountered no problem, although (as I mentioned in https://github.com/lxqt/lxqt-panel/issues/2044) I use git LXQt with Qt6 components.
I have seen that issue, it seems to me like a big coincidence that something similar has been described just 4 hours ago. I still use openbox, not kwin (it is not even installed).
I have done 2 system updates in the last 2 weeks, i think this could be something related to the previous one(I updated today but this happened before today too). Since i update at least 1 time per week, this should be cause by a recent change.
Update: Could it be related to some kind of update on KDE's packages in the last days? I have seen there was some activity on kde's packages lately.
Could it be related to some kind of update on KDE's packages in the last days?
That's possible in the case of https://github.com/lxqt/lxqt-panel/issues/2044. But since you said that you didn't use KWin, I wonder how KDE updates could have affected you.
The stranger thing is that Arch's upgrades come to Manjaro Testing after a few days at most, but I've had a stable LXQt+kwin_x11 session. Moreover, I upgraded to the Qt6-based git lxqt-panel only recently, and I had a fully stable session with the Qt5-based panel too.
IMO, an important piece of info is missing.
I have been reading the journalctl
again i have found that like 1 minute before the issue, there is a coredump in kscreen_backend
:
systemd-coredump[405123]: Process 327365 (kscreen_backend) of user 1000 dumped core.
Stack trace of thread 327365:
#0 0x00007cd7982f2d88 _ZN12QApplication7setFontERK5QFontPKc (libQt6Widgets.so.6 + 0xf2d88)
#1 0x00007cd7993a9462 _ZN17LXQtPlatformTheme12loadSettingsEv (libqtlxqt.so + 0x10462)
#2 0x00007cd7993a9c70 _ZN17LXQtPlatformTheme17onSettingsChangedEv (libqtlxqt.so + 0x10c70)
#3 0x00007cd79cf90ca9 n/a (libQt6Core.so.6 + 0x190ca9)
#4 0x00007cd79d0e7e98 n/a (libQt6Core.so.6 + 0x2e7e98)
#5 0x00007cd79cf90fab n/a (libQt6Core.so.6 + 0x190fab)
#6 0x00007cd79d0f48a8 n/a (libQt6Core.so.6 + 0x2f48a8)
#7 0x00007cd79cf90fab n/a (libQt6Core.so.6 + 0x190fab)
#8 0x00007cd79cf98530 _ZN15QSocketNotifier5eventEP6QEvent (libQt6Core.so.6 + 0x198530)
#9 0x00007cd79cf39818 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt6Core.so.6 + 0x139818)
#10 0x00007cd79d1754d1 n/a (libQt6Core.so.6 + 0x3754d1)
#11 0x00007cd79c72b199 n/a (libglib-2.0.so.0 + 0x5a199)
#12 0x00007cd79c78a3bf n/a (libglib-2.0.so.0 + 0xb93bf)
#13 0x00007cd79c72a712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
#14 0x00007cd79d1739c4 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x3739c4)
#15 0x00007cd79cf43d6e _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x143d6e)
#16 0x00007cd79cf3c2b8 _ZN16QCoreApplication4execEv (libQt6Core.so.6 + 0x13c2b8)
#17 0x000061a1edc0939a n/a (kscreen_backend_launcher + 0x439a)
#18 0x00007cd79c843cd0 n/a (libc.so.6 + 0x25cd0)
#19 0x00007cd79c843d8a __libc_start_main (libc.so.6 + 0x25d8a)
#20 0x000061a1edc09565 n/a (kscreen_backend_launcher + 0x4565)
Stack trace of thread 327385:
#0 0x00007cd79c9190bf __poll (libc.so.6 + 0xfb0bf)
#1 0x00007cd79bb5420b n/a (libxcb.so.1 + 0xd20b)
#2 0x00007cd79bb55f3d xcb_wait_for_event (libxcb.so.1 + 0xef3d)
#3 0x00007cd799a0cf4e n/a (libQt6XcbQpa.so.6 + 0x4bf4e)
#4 0x00007cd79d0a0bd3 n/a (libQt6Core.so.6 + 0x2a0bd3)
#5 0x00007cd79c8a955a n/a (libc.so.6 + 0x8b55a)
#6 0x00007cd79c926a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 327384:
#0 0x00007cd79c9190bf __poll (libc.so.6 + 0xfb0bf)
#1 0x00007cd79c78a306 n/a (libglib-2.0.so.0 + 0xb9306)
#2 0x00007cd79c72a712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
#3 0x00007cd79d1739c4 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x3739c4)
#4 0x00007cd79cf43d6e _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x143d6e)
#5 0x00007cd79d02106f _ZN7QThread4execEv (libQt6Core.so.6 + 0x22106f)
#6 0x00007cd79d5769df n/a (libQt6DBus.so.6 + 0x299df)
#7 0x00007cd79d0a0bd3 n/a (libQt6Core.so.6 + 0x2a0bd3)
#8 0x00007cd79c8a955a n/a (libc.so.6 + 0x8b55a)
#9 0x00007cd79c926a3c n/a (libc.so.6 + 0x108a3c)
ELF object binary architecture: AMD x86-64
kernel: kscreen_backend[327365] segfault at a1 ip 00007cd7982f2d88 sp 00007ffc00712880 error 4 in libQt6Widgets.so.6.6.2[7cd7982e6000+452000] likely on CPU 0 (core 0, socket 0)
kernel: Code: 49 39 de 75 cd 48 8b 05 d6 2a 5d 00 48 8b 00 4c 8b 70 08 49 8b 86 90 01 00 00 49 8b 9e 88 01 00 00 48 c1 e0 03 74 2a 0f 1f 00 <48> 8b 3b 4c 89 ee 48 83 c3 08 ff 15 90 34 5d 00 49 8b 96 90 01 00
Since this is a screen thing, it may be related.
Now, looking carefully, it seems that the dbus
errors per se happened several hours before the 'freezing' so it may not be the proper cause of my problem.
Something i have find in coredumpctl
and may shed some light into this is:
I have 2 coredumps of /usr/lib/kf6/kscreen_backend_launcher
which likely match with the 2 times i had the freezing in my system. There are also other /usr/lib/kf6/kscreen_backend_launcher
coredumps in previous dates (I even have seen /usr/lib/kf5/kscreen_backend_launcher
coredumps) but maybe something has changed in the 2 last weeks in that package that makes that coredump and system freezing.
PS: I also remember that this happened after a system update: The first time this happened, it was right after the system update(i remember that the update was ongoing and suddenly i was not able to change tabs and cpu gone wild). This time, was like 3 or 4 hours after the system update. I know i have to restart the pc after an update, but this time i did not made the reboot right after the update.
I even have seen /usr/lib/kf5/kscreen_backend_launcher coredumps
That file belongs to libkscreen5
, which I don't have here. pacman.log
shows that I had the upgrade libkscreen
5.27.11-1 → 6.0.2-3 in 2024-03-16 (which matches one of your upgrades).
libkscreen5
is needed by the Arch package lxqt-config
1.4.0-2, while my git lxqt-config
depends on libkscreen
6.0.2. Also, my previous version of lxqt-config
(1.4.0) and all other Qt5-based LXQt components were self-compiled.
I'm not saying that the problem you see is related to libkscreen5
, but it may need investigation.
Now, I'm really suspicious of the recent changes in KDE Frameworks. In spite of including "5" in their Arch package names, something may have not been backward compatible.
That may explain why I don't see any issue here: I don't have those packages with "5" in their names.
If my suspicion is right, some components of LXQt 1.4.0 should be broken after the recent Arch upgrades. Whether there's a way of fixing that before LXQt 2.0.0, I have no idea.
@yan12125, any thought on this?
That backtrace for the 'kscreen_backend' segfault looks awfully similar to the one I mentioned here:
In spite of similarities, I doubt that they're related. https://github.com/lxqt/lxqt-qtplugin/issues/83 was about an old problem that happened when settings were applied while kglobalacceld was running.
An update on the topic:
Today i had a kscreen_backend
coredump, but this time there was no need to force shutdown the system. I suspect this is caused because this time i did not had updated the system (i wonder if some kind of service or binary does not work after updating the system without a proper reboot).
The coredump details were exactly the same as the one i shared 6 comments above. This time i was opening lxqt-config-appearance
, and i only changed the color palette from default->dark and the GTK themes to darker variants.
During the program applying the changes, more or less, the coredump happened. My last system upgrade was in 2024-03-28, yet nothing related to lxqt or Kde was upgraded. pacman.log
relevant lines may be:
upgraded linux (6.8.1.arch1-1 -> 6.8.2.arch1-1)
upgraded linux-headers (6.8.1.arch1-1 -> 6.8.2.arch1-1)
upgraded libx11 (1.8.8-1 -> 1.8.8-2)
Between other not related programs which were upgraded (i.e electron).
Later attempts to reproduce the issue by changing colors in lxqt-config-appearance dont trigger the coredump on kscreen_backend.
Another thing i have to add is that i have noticed that after startup, lxqt-config-monitor
seems to crash too, without noticeable issues on my side.
One of the Stack trace of thread
lines may be related to this issue,because it says:
`
Later attempts to reproduce the issue by changing colors in lxqt-config-appearance dont trigger the coredump on kscreen_backend.
@Chiitoo mentioned the similarities of backtraces of kscreen_backend earlier. Although https://github.com/lxqt/lxqt-qtplugin/issues/83 was about kglobalacceld, the fix was quite general. So, I recommend you upgrade your Qt6-based git lxqt-qtplugin to the latest git source.
If you're familiar with making packages from sources, you might also want to upgrade your Qt5-based lxqt-qtplugin 1.4.0 to this branch: https://github.com/lxqt/lxqt-qtplugin/tree/fix_fontapply. See https://github.com/lxqt/lxqt/discussions/2546 for the main reason, but the Qt6-based fix is also included in that Qt5 branch.
I have updated the lxqt-qtplugin
to the branch fix_fontaplly
using the AUR lxqt-qtplugin-git
since i am still in qt5.
For this, i used source = https://github.com/lxqt/lxqt-qtplugin/archive/refs/heads/fix_fontapply.zip
and changed the dependencies shown in the AUR package for the ones i have: libqt6xdg-git
libfm-qt6-git
and lxqt-build-tools-qt6-git
After successfully installing the package (prior renaming the folder obtained via the .zip) i rebooted. After reboot, i still see the lxqt-config-monitor
crash on startup, but i yet have to see what happens with kscreen_backend
(which seems to happen randomly).
PS: before doing this, i did a system upgrade, pacman.log
shows:
upgraded libkscreen (6.0.2-3 -> 6.0.3-1)
I have updated xqt-qtplugin. to the branch fix_fontaplly....
Therefore, if you see a kscreen_backend
problem after that, it couldn't be related to https://github.com/lxqt/lxqt-qtplugin/issues/83.
BTW, we'll change the name of that branch from fix_fontaplly
to 1.4
soon, for a better maintenance.
i still see the lxqt-config-monitor crash on startup
You mean its Qt5 version belonging to lxqt-config 1.4.0? It depends on libkscreen5
, not libkscreen
.
A backtrace?
Yes, the 1.4.0 version which is qt5-based (the one present in arch repositories).
The lxqt-config-monitor
backtrace looks exactly the same as the ones i had before this change. But since i did not shared those, here it goes the last one (This was obtained after the changes mentioned in my last comment):
Storage: /var/lib/systemd/coredump/core.lxqt-config-mon.1000.96139daa858c404b832570678a7d9e64.669.1711804970000000.zst (present)
Size on Disk: 796.5K
Message: Process 669 (lxqt-config-mon) of user 1000 dumped core.
Stack trace of thread 669:
#0 0x00007864a66b7098 _ZNK7KScreen6Config7outputsEv (libKF5Screen.so.8 + 0x16098)
#1 0x0000636ed21ab670 n/a (lxqt-config-monitor + 0x1f670)
#2 0x0000636ed21ac134 n/a (lxqt-config-monitor + 0x20134)
#3 0x00007864a52c89a7 n/a (libQt5Core.so.5 + 0x2c89a7)
#4 0x00007864a66b2634 _ZN7KScreen15ConfigOperation8finishedEPS0_ (libKF5Screen.so.8 + 0x11634)
#5 0x00007864a66b30a9 n/a (libKF5Screen.so.8 + 0x120a9)
#6 0x00007864a52bb4da _ZN7QObject5eventEP6QEvent (libQt5Core.so.5 + 0x2bb4da)
#7 0x00007864a5293a68 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt5Core.so.5 + 0x293a68)
#8 0x00007864a52989cb _ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QThreadData (libQt5Core.so.5 + 0x2989cb)
#9 0x00007864a52dea48 n/a (libQt5Core.so.5 + 0x2dea48)
#10 0x00007864a492b199 n/a (libglib-2.0.so.0 + 0x5a199)
#11 0x00007864a498a3bf n/a (libglib-2.0.so.0 + 0xb93bf)
#12 0x00007864a492a712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
#13 0x00007864a52e288c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2e288c)
#14 0x00007864a5292774 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x292774)
#15 0x00007864a5293c13 _ZN16QCoreApplication4execEv (libQt5Core.so.5 + 0x293c13)
#16 0x0000636ed219a275 n/a (lxqt-config-monitor + 0xe275)
#17 0x00007864a4a43cd0 n/a (libc.so.6 + 0x25cd0)
#18 0x00007864a4a43d8a __libc_start_main (libc.so.6 + 0x25d8a)
#19 0x0000636ed219ad45 _start (lxqt-config-monitor + 0xed45)
Stack trace of thread 677:
#0 0x00007864a4b190bf __poll (libc.so.6 + 0xfb0bf)
#1 0x00007864a3df520b n/a (libxcb.so.1 + 0xd20b)
#2 0x00007864a3df6f3d xcb_wait_for_event (libxcb.so.1 + 0xef3d)
#3 0x00007864a14a30e2 n/a (libQt5XcbQpa.so.5 + 0x5d0e2)
#4 0x00007864a50eb88a n/a (libQt5Core.so.5 + 0xeb88a)
#5 0x00007864a4aa955a n/a (libc.so.6 + 0x8b55a)
#6 0x00007864a4b26a3c n/a (libc.so.6 + 0x108a3c)
Stack trace of thread 676:
#0 0x00007864a4b190bf __poll (libc.so.6 + 0xfb0bf)
#1 0x00007864a498a306 n/a (libglib-2.0.so.0 + 0xb9306)
#2 0x00007864a492a712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
#3 0x00007864a52e288c _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt5Core.so.5 + 0x2e288c)
#4 0x00007864a5292774 _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt5Core.so.5 + 0x292774)
#5 0x00007864a50ef666 _ZN7QThread4execEv (libQt5Core.so.5 + 0xef666)
#6 0x00007864a6557a9a n/a (libQt5DBus.so.5 + 0x17a9a)
#7 0x00007864a50eb88a n/a (libQt5Core.so.5 + 0xeb88a)
#8 0x00007864a4aa955a n/a (libc.so.6 + 0x8b55a)
#9 0x00007864a4b26a3c n/a (libc.so.6 + 0x108a3c)
ELF object binary architecture: AMD x86-64
Working on and testing the Qt6 port of LXQt, I don't have the Qt5-based lxqt-config or libkscreen5
anymore, but the backtrace shows a cash in libkscreen5
(unfortunately, there's no more detail).
Yes, i will run the corresponding gdb
when i recover normal internet (maybe on next Thursday).
coredumpctl gdb /usr/bin/lxqt-config-monitor
coredumpctl gdb kscreen_backend
I guess that if the problem is not present at the moment in the Qt6, the issue may be on the libkscreen5
side.
In the meanwhile, i will check for kscreen_backend
coredumps.
Thank you.
I guess that if the problem is not present at the moment in the Qt6
Right, everything seems normal here.
Well, a few days have passed, and there were no more kscreen_backend
coredumps (and no more system freezing and cpu going to 100%).
The lxqt-config-monitor
crash is present but it does not modify anything and system works well overall.
I was able to run coredumpctl gdb kscreen_backend
and it shows something that may relate this issue with the previously described one. I will attach the report in a .txt just for the record.
Here is the relevant part:
#2 QApplication::setFont (font=..., className=0x0) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.3/src/widgets/kernel/qapplication.cpp:1373
#3 0x0000796e4512a462 in LXQtPlatformTheme::loadSettings() () from /usr/lib/qt6/plugins/platformthemes/libqtlxqt.so
#4 0x0000796e4512ac70 in LXQtPlatformTheme::onSettingsChanged() () from /usr/lib/qt6/plugins/platformthemes/libqtlxqt.so
I think this issue can be closed.
coredumpctl gdb /usr/bin/lxqt-config-monitor
was executed too, but the information dropped was not much relevant, it complains about KScreen
and libkscreen5
.
I will let you close the issue, in case you would like to see any more information about it.
Thank you very much @tsujan and @Chiitoo
The crash in the Qt6-based kscreen_backend should have been fixed after https://github.com/lxqt/lxqt-qtplugin/commit/b73fc19b510f4eca9be11e952f1e91e68b3b540d (related @Chiitoo's report).
Also, the Qt5-based kscreen_backend shouldn't crash after https://github.com/lxqt/lxqt-qtplugin/tree/1.4 (based on which, lxqt-qtplugin 1.4.1 will be released soon) for the same reason.
Well, it seems like the crash still is present. I obtained 2 today (i have been playing with WMs and using lxqt-config-appareance
).
The error or issue seems to point to the same thing as the last gdb
i have shared (from 4 days ago).
#0 QApplication::setFont (font=..., className=0x0) at /usr/src/debug/qt6-base/qtbase-everywhere-src-6.6.3/src/widgets/kernel/qapplication.cpp:1374
#1 0x0000768499554462 in LXQtPlatformTheme::loadSettings() () from /usr/lib/qt6/plugins/platformthemes/libqtlxqt.so
#2 0x0000768499554c70 in LXQtPlatformTheme::onSettingsChanged() () from /usr/lib/qt6/plugins/platformthemes/libqtlxqt.so
Fortunately this did not crash the system but the problem is somehow around.
Well, it seems like the crash still is present
If I were you, I'd check if Openbox has anything to do with this, by changing my WM (as in https://github.com/lxqt/lxqt-config/issues/987).
I'm not saying that Openbox is the culprit, but there have been cases where Openbox has caused serious troubles. Personally, I don't trust an app whose development stopped years ago to play a role as sensitive as that of a WM.
An update into this:
I have been using xfwm4 for a while to test the keyboard issue i have had.
In the meanwhile, i have been following what happens with this issue.
After i have installed the fix_fontapply
(now called 1.4
) branch i have not seen much problems with this specific issue, but mostly because i always restarted the system after a system update.
A few times i did not restarted the system for different reasons, and in some of them i noticed the following.
Continuing with the fix_fontapply
issue, which is triggered after changing the color palette in lxqt-config-appearance
now i have noticed that from time to time, the kscreen_backend_launcher
module crashes, and that triggers an issue in Xorg process which makes the CPU go to 70% aproximately, which is better than the system freezing i was having, but forces me to do something as rebooting, logout and login or restarting the X session with:
sudo systemctl restart display-manager
I have ran:
coredumpctl gdb /usr/lib/kf6/kscreen_backend_launcher
and the result seems to point to the font issue again (and that's why i add this long comment with the details):
#0 0x00007e25750f4ff8 _ZN12QApplication7setFontERK5QFontPKc (libQt6Widgets.so.6 + 0xf4ff8)
#1 0x00007e2576aa0462 _ZN17LXQtPlatformTheme12loadSettingsEv (libqtlxqt.so + 0x10462)
#2 0x00007e2576aa0c70 _ZN17LXQtPlatformTheme17onSettingsChangedEv (libqtlxqt.so + 0x10c70)
And the where
command inside gdb shows:
#0 QApplication::setFont (font=..., className=0x0) at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:1368
Downloading source file /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp --> **this line is gdb dialog**
1368 QCoreApplication::sendEvent(*it, &e);
Here is the output of the coredump, it may contain more relevant information:
Stack trace of thread 100731:
#0 0x00007e25750f4ff8 _ZN12QApplication7setFontERK5QFontPKc (libQt6Widgets.so.6 + 0xf4ff8)
#1 0x00007e2576aa0462 _ZN17LXQtPlatformTheme12loadSettingsEv (libqtlxqt.so + 0x10462)
#2 0x00007e2576aa0c70 _ZN17LXQtPlatformTheme17onSettingsChangedEv (libqtlxqt.so + 0x10c70)
#3 0x00007e257a797549 n/a (libQt6Core.so.6 + 0x197549)
#4 0x00007e257a8f6980 n/a (libQt6Core.so.6 + 0x2f6980)
#5 0x00007e257a79784b n/a (libQt6Core.so.6 + 0x19784b)
#6 0x00007e257a903a08 n/a (libQt6Core.so.6 + 0x303a08)
#7 0x00007e257a79784b n/a (libQt6Core.so.6 + 0x19784b)
#8 0x00007e257a7a04ba _ZN15QSocketNotifier5eventEP6QEvent (libQt6Core.so.6 + 0x1a04ba)
#9 0x00007e257a73daa8 _ZN16QCoreApplication15notifyInternal2EP7QObjectP6QEvent (libQt6Core.so.6 + 0x13daa8)
#10 0x00007e257a985bf1 n/a (libQt6Core.so.6 + 0x385bf1)
#11 0x00007e2579deb199 n/a (libglib-2.0.so.0 + 0x5a199)
#12 0x00007e2579e4a3bf n/a (libglib-2.0.so.0 + 0xb93bf)
#13 0x00007e2579dea712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
#14 0x00007e257a983cf4 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x383cf4)
#15 0x00007e257a745c3e _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x145c3e)
#16 0x00007e257a7416a8 _ZN16QCoreApplication4execEv (libQt6Core.so.6 + 0x1416a8)
#17 0x0000592f5af3c39a n/a (kscreen_backend_launcher + 0x439a)
#18 0x00007e257a041d4a n/a (libc.so.6 + 0x25d4a)
#19 0x00007e257a041e0c __libc_start_main (libc.so.6 + 0x25e0c)
#20 0x0000592f5af3c565 n/a (kscreen_backend_launcher + 0x4565)
Stack trace of thread 100733:
#0 0x00007e257a11d9ed __poll (libc.so.6 + 0x1019ed)
#1 0x00007e2579e4a306 n/a (libglib-2.0.so.0 + 0xb9306)
#2 0x00007e2579dea712 g_main_context_iteration (libglib-2.0.so.0 + 0x59712)
#3 0x00007e257a983cf4 _ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEventsFlagEE (libQt6Core.so.6 + 0x383cf4)
#4 0x00007e257a745c3e _ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0x145c3e)
#5 0x00007e257a82cabf _ZN7QThread4execEv (libQt6Core.so.6 + 0x22cabf)
#6 0x00007e257b59715f n/a (libQt6DBus.so.6 + 0x2c15f)
#7 0x00007e257a8adbc3 n/a (libQt6Core.so.6 + 0x2adbc3)
#8 0x00007e257a0aa1cf n/a (libc.so.6 + 0x8e1cf)
#9 0x00007e257a12b6ec n/a (libc.so.6 + 0x10f6ec)
Stack trace of thread 100734:
#0 0x00007e257a11d9ed __poll (libc.so.6 + 0x1019ed)
#1 0x00007e25792eb20b n/a (libxcb.so.1 + 0xd20b)
#2 0x00007e25792ecf3d xcb_wait_for_event (libxcb.so.1 + 0xef3d)
#3 0x00007e2576bacf1e n/a (libQt6XcbQpa.so.6 + 0x4bf1e)
#4 0x00007e257a8adbc3 n/a (libQt6Core.so.6 + 0x2adbc3)
#5 0x00007e257a0aa1cf n/a (libc.so.6 + 0x8e1cf)
#6 0x00007e257a12b6ec n/a (libc.so.6 + 0x10f6ec)
ELF object binary architecture: AMD x86-64
I know that LXQt 2.0 will arrive soon in the archlinux repositories and i will have to see what happens in there, but i considered important to show this before the switch to the new version.
Information:
lxqt-qt6plugin-git 1.3.0.3.g8e8a2b3-1
lxqt-qtplugin-git db40b8a-1 (fix_fontapply)
LXQt 1.4 (not using qt6 as far as i understand)
I just realized that i have had lxqt-qt6plugin-git 1.3.0.3.g8e8a2b3-1
installed along the qt5 version (i suppose that the system still uses the qt5 version, but i will try what happens with that one removed. I installed it to obtain qt6 integration in the past.
A few times i did not restarted the system for different reasons, and in some of them i noticed the following.
If a problem happened after a system upgrade here, then I'd know that it should be about the system. If it disappeared after a reboot, I'd conclude that some basic daemons/processes needed to be restarted before having a stable system.
Hi, this issue could be closed. In the followed time to this report, i have not experienced this anymore (and nobody else has experienced it either).
I guess this was fixed somehow, in teh qt6 libkscreen version, or something was changes (indirectly) in the lxqt-panel configuration that made this solved.
Can still be reopened.
Expected Behavior
Nothing, normal system behavior.
Current Behavior
System panel and actions freezes and crash on random times(at the moment, this happened to me just 2 or 3 times). The mouse is not able to click things but it conserves the movement. Hotkeys seem to work, somehow, (qps shorcut key seems to be activated because the tray icon is loaded but qps does not show in the screen) Time clock works( HH:MM:SS change) CPU goes to 100% and i am forced to physically shutdown the PC.
Possible Solution
No idea.
Steps to Reproduce (for bugs)
I have no steps to reproduce it, seems to happen on random time.
Context
Some of the
journalctl
messages i have seen are:lxqt-panel[750]: void DBusMenuImporter::slotGetLayoutFinished(QDBusPendingCallWatcher*): "Remote peer disconnected"
lxqt-panel[750]: Error on DBus request(:1.445,/StatusNotifierItem): QDBusError(org.freedesktop.DBus.Error.NoReply, Remote peer disconnected)
lxqt-panel[750]: Error on DBus request(:1.445,/StatusNotifierItem): QDBusError(org.freedesktop.DBus.Error.UnknownObject, No such object path '/StatusNotifierItem')
lxqt-panel[750]: Error on DBus request(:1.38,/StatusNotifierItem): QDBusError(org.freedesktop.DBus.Error.UnknownProperty, Property org.kde.StatusNotifierItem.IconName was not found in object /StatusNotifierItem)
System Information
I have the full journactl log from where i have extracted those lines, i case more information is needed. Maybe this is related to the
dbus-broker
change made in Archlinux in January 9th ?PS: I have the following AUR packages which may be involved: