https://bugs.kde.org/show_bug.cgi?id=482950
--- Comment #11 from Joe S <jmscdba+...@gmail.com> ---
This problem just seems to get worse with each update.
I have replicated it on a Tumbleweed vm running the latest build 20240507.
My KDE Neon test environment updated to the last version just displays the blue
screen that everyone else is complaining about.
Those are NEW fresh installations that were updated to the latest builds so
nothing in the current environment where the problem was originally found comes
into play.
Trying to connect using krdc 24.02.2 now just core dumps
systemd-coredump[758]: [🡕] Process 744 (krdc) of user 1000 dumped core.
Stack trace of thread 744:
#0 0x00007fee3c013bf1 n/a
(libkrdc_rdpplugin.so + 0xebf1)
#1 0x00007fee3c01948d n/a
(libkrdc_rdpplugin.so + 0x1448d)
#2 0x00007fee43ddc245
_ZN15HostPreferences10showDialogEP7QWidget (libkrdccore.so.5 + 0xb245)
#3 0x00005619e047d93b n/a (krdc +
0x3293b)
#4 0x00005619e0467017 n/a (krdc +
0x1c017)
#5 0x00007fee4162a1f0
__libc_start_call_main (libc.so.6 + 0x2a1f0)
#6 0x00007fee4162a2b9
__libc_start_main@@GLIBC_2.34 (libc.so.6 + 0x2a2b9)
#7 0x00005619e04672d5 n/a (krdc +
0x1c2d5)
Stack trace of thread 745:
#0 0x00007fee4170578f __poll
(libc.so.6 + 0x10578f)
#1 0x00007fee405ce2ff n/a
(libglib-2.0.so.0 + 0x5f2ff)
#2 0x00007fee405cea0c
g_main_context_iteration (libglib-2.0.so.0 + 0x5fa0c)
#3 0x00007fee421c0a8c
_ZN20QEventDispatcherGlib13processEventsE6QFlagsIN10QEventLoop17ProcessEve>
#4 0x00007fee41f9979b
_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE (libQt6Core.so.6 + 0>
#5 0x00007fee42074cb4
_ZN7QThread4execEv (libQt6Core.so.6 + 0x274cb4)
#6 0x00007fee41d7b6fa n/a
(libQt6DBus.so.6 + 0x386fa)
#7 0x00007fee420ecea9 n/a
(libQt6Core.so.6 + 0x2ecea9)
#8 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#9 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 747:
#0 0x00007fee4168effe
__futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007fee41691d40
pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40)
#2 0x00007fee35d10e5b n/a
(iris_dri.so + 0x110e5b)
#3 0x00007fee35d06e67 n/a
(iris_dri.so + 0x106e67)
#4 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#5 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 746:
#0 0x00007fee4170578f __poll
(libc.so.6 + 0x10578f)
#1 0x00007fee3f6ed8aa n/a
(libxcb.so.1 + 0xe8aa)
#2 0x00007fee3f6ef41c
xcb_wait_for_event (libxcb.so.1 + 0x1041c)
#3 0x00007fee3dd34e30 n/a
(libQt6XcbQpa.so.6 + 0x5de30)
#4 0x00007fee420ecea9 n/a
(libQt6Core.so.6 + 0x2ecea9)
#5 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#6 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 748:
#0 0x00007fee4168effe
__futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007fee41691d40
pthread_cond_wait@@GLIBC_2.3.2 (libc.so.6 + 0x91d40)
#2 0x00007fee35d10e5b n/a
(iris_dri.so + 0x110e5b)
#3 0x00007fee35d06e67 n/a
(iris_dri.so + 0x106e67)
#4 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#5 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 752:
#0 0x00007fee4168effe
__futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007fee41692065
pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007fee420f9413
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9>
#3 0x00007fee420f3d49 n/a
(libQt6Core.so.6 + 0x2f3d49)
#4 0x00007fee420ecea9 n/a
(libQt6Core.so.6 + 0x2ecea9)
#5 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#6 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 753:
#0 0x00007fee4168effe
__futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007fee41692065
pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007fee420f9413
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9>
#3 0x00007fee420f3d49 n/a
(libQt6Core.so.6 + 0x2f3d49)
#4 0x00007fee420ecea9 n/a
(libQt6Core.so.6 + 0x2ecea9)
#5 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#6 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 754:
#0 0x00007fee4168effe
__futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007fee41692065
pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007fee420f9413
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9>
#3 0x00007fee420f3d49 n/a
(libQt6Core.so.6 + 0x2f3d49)
#4 0x00007fee420ecea9 n/a
(libQt6Core.so.6 + 0x2ecea9)
#5 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#6 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 756:
#0 0x00007fee4168effe
__futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007fee41692065
pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007fee420f9413
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9>
#3 0x00007fee420f3d49 n/a
(libQt6Core.so.6 + 0x2f3d49)
#4 0x00007fee420ecea9 n/a
(libQt6Core.so.6 + 0x2ecea9)
#5 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#6 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
Stack trace of thread 755:
#0 0x00007fee4168effe
__futex_abstimed_wait_common (libc.so.6 + 0x8effe)
#1 0x00007fee41692065
pthread_cond_timedwait@@GLIBC_2.3.2 (libc.so.6 + 0x92065)
#2 0x00007fee420f9413
_ZN14QWaitCondition4waitEP6QMutex14QDeadlineTimer (libQt6Core.so.6 + 0x2f9>
#3 0x00007fee420f3d49 n/a
(libQt6Core.so.6 + 0x2f3d49)
#4 0x00007fee420ecea9 n/a
(libQt6Core.so.6 + 0x2ecea9)
#5 0x00007fee41692bb2
start_thread (libc.so.6 + 0x92bb2)
#6 0x00007fee4171400c __clone3
(libc.so.6 + 0x11400c)
ELF object binary architecture:
AMD x86-64
How can you break such critical functionality for users and not make it a
priority OR at least rollback the changes until the problem is fixed?
My Debian test environment using plasma 5.27.5 and krdc 22.12.3 works fine.
My Debian SID test environment using plasma 5.27.10 and krdc 23.08.3 works
fine.
Something with krdc is SERIOUSLY broken when I can replicate the problems with
krdc on different distros.
I have been in discussion with the xrdp developers for since March 2024
regarding the problem.
In EVERY case where krdc fails with either the blue screen and never displaying
the desktop or where krdc core dumps, I can run xfreerdp to make the connection
and it works WITHOUT ANY issue.
It is my understanding, that krdc is at least partially using freerdp behind
the scenes so clearly something in krdc is the source of the problem since
xfreerdp works.
How can we escalate this so that it such a critical component gets some
priority ?
--
You are receiving this mail because:
You are watching all bug changes.
