Bug 488687 - krdpserver or the portal it uses freezes after a non-H264 capable client attempts to connect
Summary: krdpserver or the portal it uses freezes after a non-H264 capable client atte...
Status: RESOLVED FIXED
Alias: None
Product: KRdp
Classification: Plasma
Component: general (show other bugs)
Version: 6.1.0
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Unassigned bugs mailing-list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2024-06-18 20:18 UTC by Synthetic451
Modified: 2024-07-18 02:35 UTC (History)
4 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.1.3
Sentry Crash Report:


Attachments
Log of connection failure from Android app that triggers this bug (4.03 KB, text/plain)
2024-06-18 20:18 UTC, Synthetic451
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Synthetic451 2024-06-18 20:18:10 UTC
Created attachment 170608 [details]
Log of connection failure from Android app that triggers this bug

***
If you're not sure this is actually a bug, instead post about it at https://discuss.kde.org

If you're reporting a crash, attach a backtrace with debug symbols; see https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports
***

SUMMARY
I tried to connect to Krdp using Microsoft's Remote Desktop app for Android before reading the disclaimer on the Git readme saying that it doesn't work at the moment. I then attempted to shutdown the server by toggling off "Enable RDP server" in the kcm panel, but that did not kill the krdpserver process. Going to another kcm panel and then returning to "Remote Desktop" puts the setting back to Enabled. In the logs, I see "Stopping KRDP Server", but not "Stopped KRDP Server" like it usually does.

This only seems to happen when I connect with Microsoft's remote desktop app. Connecting and disconnecting with Remmina does not trigger this bug

STEPS TO REPRODUCE
1. Connect to Krdp using Microsoft's Remote Desktop app for Android
2. The connection will fail
3. Disable the "Enable RDP Server" setting

OBSERVED RESULT
krdpserver process never terminates

EXPECTED RESULT
krdpserver process should terminate

SOFTWARE/OS VERSIONS
Operating System: Arch Linux 
KDE Plasma Version: 6.1.0
KDE Frameworks Version: 6.3.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-arch1-1 (64-bit)
Graphics Platform: Wayland
Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor
Memory: 31.3 GiB of RAM
Graphics Processor: NVIDIA GeForce RTX 3090/PCIe/SSE2
Product Name: X570 Taichi

ADDITIONAL INFORMATION
Comment 1 Akseli Lahtinen 2024-06-24 07:19:56 UTC
Can confirm, something freezes the krdpserver application (or possibly the portal) and it gets stuck as a process. However for me it resolved itself after couple minutes and turned off the server, when toggling it off settings.

Operating System: Fedora Linux 40
KDE Plasma Version: 6.1.80
KDE Frameworks Version: 6.4.0
Qt Version: 6.7.1
Kernel Version: 6.9.5-200.fc40.x86_64 (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 6600
Comment 2 Akseli Lahtinen 2024-07-10 09:25:45 UTC
A potential backtrace

Program terminated with signal SIGABRT, Aborted.
#0  0x00007f540bca2be9 in __futex_abstimed_wait_common64 (private=0, futex_word=0x7f53e800f820, expected=0,
op=393, abstime=0x0, cancel=true) at futex-internal.c:57
Downloading source file /usr/src/debug/glibc-2.39-17.fc40.x86_64/nptl/futex-internal.c
57          return INTERNAL_SYSCALL_CANCEL (futex_time64, futex_word, op, expected,
[Current thread is 1 (Thread 0x7f53fcaa33c0 (LWP 22224))]
Missing separate debuginfos, use: dnf debuginfo-install ffmpeg-libs-6.1.1-11.fc40.x86_64 x264-libs-0.164-13.20231001git31e19f92.fc40.x86_64 x265-libs-3.6-2.fc40.x86_64
(gdb) bt
#0  0x00007f540bca2be9 in __futex_abstimed_wait_common64
(private=0, futex_word=0x7f53e800f820, expected=0, op=393, abstime=0x0, cancel=true)
at futex-internal.c:57
#1  __futex_abstimed_wait_common
(futex_word=futex_word@entry=0x7f53e800f820, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0, cancel=cancel@entry=true) at futex-internal.c:87
#2  0x00007f540bca2c6f in __GI___futex_abstimed_wait_cancelable64
(futex_word=futex_word@entry=0x7f53e800f820, expected=expected@entry=0, clockid=clockid@entry=0, abstime=abstime@entry=0x0, private=private@entry=0) at futex-internal.c:139
#3  0x00007f540bca5639 in __pthread_cond_wait_common
(cond=0x7f53e800f7f8, mutex=<optimized out>, clockid=0, abstime=0x0) at pthread_cond_wait.c:503
#4  ___pthread_cond_wait (cond=0x7f53e800f7f8, mutex=<optimized out>) at pthread_cond_wait.c:618
#5  0x00007f540c560efb in QWaitConditionPrivate::wait (this=0x7f53e800f7d0, deadline=...)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/thread/qwaitcondition_unix.cpp:102
#6  QWaitCondition::wait (this=this@entry=0x20ed12e8, mutex=mutex@entry=0x20ed12c8, deadline=...)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/thread/qwaitcondition_unix.cpp:180
#7  0x00007f540c5542c1 in QThread::wait (this=<optimized out>, deadline=...)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/thread/qthread_unix.cpp:775
#8  0x00007f540de566e8 in PipeWireBaseEncodedStream::refresh (this=this@entry=0x20e7b7a0)
at /usr/include/qt6/QtCore/qdeadlinetimer.h:31
#9  0x00007f540de5695e in PipeWireBaseEncodedStream::setActive (this=0x20e7b7a0, active=false)
at /home/akseli/Repositories/kde/src/kpipewire/src/pipewirebaseencodedstream.cpp:148
#10 0x00007f540c3fc872 in QtPrivate::QSlotObjectBase::call
(this=0x7f53e8010c60, r=<optimized out>, a=0x7ffcdaa9f8d0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qobjectdefs_impl.h:469
#11 doActivate<false> (sender=0x20f27720, signal_index=0, argv=0x7ffcdaa9f8d0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qobject.cpp:4086
#12 0x00007f540c3f2b47 in QMetaObject::activate
(sender=sender@entry=0x20f27720, m=m@entry=0x7f540c884ea0, local_signal_index=local_signal_index@entry=0, argv=argv@entry=0x7ffcdaa9f8d0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qobject.cpp:4146
#13 0x00007f540c3f2c01 in QObject::destroyed (this=this@entry=0x20f27720, _t1=<optimized out>,
_t1@entry=0x20f27720)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/redhat-linux-build/src/corelib/kernel/moc_qobject.cpp:229--Type <RET> for more, q to quit, c to continue without paging--c

\#14 0x00007f540c3f948e in QObject::~QObject (this=<optimized out>, __in_chrg=<optimized out>)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qobject.cpp:1074
#15 0x00007f540e5c1369 in KRdp::VideoStream::~VideoStream (this=0x20f27720, __in_chrg=<optimized out>)
at /home/akseli/Repositories/kde/src/krdp/src/VideoStream.cpp:155
#16 0x00007f540e5b23fa in std::default_delete<KRdp::VideoStream>::operator()
(this=<optimized out>, __ptr=<optimized out>) at /usr/include/c++/14/bits/unique_ptr.h:87
#17 std::unique_ptr<KRdp::VideoStream, std::default_delete<KRdp::VideoStream> >::~unique_ptr
(this=0x20bdc330, __in_chrg=<optimized out>) at /usr/include/c++/14/bits/unique_ptr.h:398
#18 KRdp::RdpConnection::Private::~Private (this=0x20bdc310, __in_chrg=<optimized out>)
at /home/akseli/Repositories/kde/src/krdp/src/RdpConnection.cpp:136
#19 std::default_delete<KRdp::RdpConnection::Private>::operator() (this=<optimized out>, __ptr=0x20bdc310)
at /usr/include/c++/14/bits/unique_ptr.h:93
#20 std::default_delete<KRdp::RdpConnection::Private>::operator() (this=<optimized out>, __ptr=0x20bdc310)
at /usr/include/c++/14/bits/unique_ptr.h:87
#21 std::unique_ptr<KRdp::RdpConnection::Private, std::default_delete<KRdp::RdpConnection::Private> >::~unique_ptr (this=0x20f27790, __in_chrg=<optimized out>) at /usr/include/c++/14/bits/unique_ptr.h:398
#22 KRdp::RdpConnection::~RdpConnection (this=0x20f27780, __in_chrg=<optimized out>)
at /home/akseli/Repositories/kde/src/krdp/src/RdpConnection.cpp:192
#23 0x00007f540e5b24a9 in KRdp::RdpConnection::~RdpConnection (this=0x20f27780, __in_chrg=<optimized out>)
at /home/akseli/Repositories/kde/src/krdp/src/RdpConnection.cpp:192
#24 0x00007f540c3edd4b in QObject::event (this=0x7ffcdaaa0330, e=0x7f53a801a9d0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qobject.cpp:1452
#25 0x00007f540d58b218 in QApplicationPrivate::notify_helper
(this=<optimized out>, receiver=0x7ffcdaaa0330, e=0x7f53a801a9d0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/widgets/kernel/qapplication.cpp:3287
#26 0x00007f540c396dc8 in QCoreApplication::notifyInternal2 (receiver=0x7ffcdaaa0330, event=0x7f53a801a9d0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1142
#27 0x00007f540c39702d in QCoreApplication::sendEvent (receiver=<optimized out>, event=<optimized out>)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1583
#28 0x00007f540c39ab91 in QCoreApplicationPrivate::sendPostedEvents
(receiver=0x0, event_type=0, data=0x20b883c0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1940
#29 0x00007f540c39ae3d in QCoreApplication::sendPostedEvents
(receiver=<optimized out>, event_type=<optimized out>)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qcoreapplication.cpp:1797
#30 0x00007f540c6858ef in postEventSourceDispatch (s=0x20c29bd0)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:244
#31 0x00007f540c10ee8c in g_main_dispatch (context=0x7f53e8000f00) at ../glib/gmain.c:3344
#32 g_main_context_dispatch_unlocked (context=0x7f53e8000f00) at ../glib/gmain.c:4152
#33 0x00007f540c170c98 in g_main_context_iterate_unlocked.isra.0
(context=context@entry=0x7f53e8000f00, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at ../glib/gmain.c:4217
#34 0x00007f540c110383 in g_main_context_iteration (context=0x7f53e8000f00, may_block=1)
at ../glib/gmain.c:4282
#35 0x00007f540c6850a3 in QEventDispatcherGlib::processEvents (this=0x20b43870, flags=...)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/kernel/qeventdispatcher_glib.cpp:394
#36 0x00007f540c3a3b03 in QEventLoop::exec (this=this@entry=0x7ffcdaa9fe60, flags=..., flags@entry=...)
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/global/qflags.h:34
#37 0x00007f540c39f9bc in QCoreApplication::exec ()
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/corelib/global/qflags.h:74
#38 0x00007f540cbd67ed in QGuiApplication::exec ()
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/gui/kernel/qguiapplication.cpp:1926
#39 0x00007f540d58b189 in QApplication::exec ()
at /usr/src/debug/qt6-qtbase-6.7.2-2.fc40.x86_64/src/widgets/kernel/qapplication.cpp:2555
#40 0x000000000040710a in main (argc=<optimized out>, argv=<optimized out>)
at /home/akseli/Repositories/kde/src/krdp/server/main.cpp:112
Comment 3 Bug Janitor Service 2024-07-10 14:49:33 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/kpipewire/-/merge_requests/155
Comment 4 Arjen Hiemstra 2024-07-15 11:00:07 UTC
Git commit 2e1c3bbd6b915ac55488ed815de1e439351b2488 by Arjen Hiemstra.
Committed on 10/07/2024 at 14:49.
Pushed by ahiemstra into branch 'master'.

produce: Properly cleanup on deactivate in all cases

We may end up calling deactivate with a PipeWire stream that is not yet
streaming. In that case calling `setActive(false)` on the stream will do
nothing and not cause a state change, so our cleanup code is never ran,
which may cause hangs because an application is waiting for the encoder
to finish. So ensure we do cleanup properly when the stream is not in a
streaming state.

M  +16   -13   src/pipewireproduce.cpp

https://invent.kde.org/plasma/kpipewire/-/commit/2e1c3bbd6b915ac55488ed815de1e439351b2488
Comment 5 Arjen Hiemstra 2024-07-15 11:01:45 UTC
Git commit 9f4c61d80bd01a92ebbcc0c89d7d7d12b9d12079 by Arjen Hiemstra.
Committed on 15/07/2024 at 11:00.
Pushed by ahiemstra into branch 'Plasma/6.1'.

produce: Properly cleanup on deactivate in all cases

We may end up calling deactivate with a PipeWire stream that is not yet
streaming. In that case calling `setActive(false)` on the stream will do
nothing and not cause a state change, so our cleanup code is never ran,
which may cause hangs because an application is waiting for the encoder
to finish. So ensure we do cleanup properly when the stream is not in a
streaming state.


(cherry picked from commit 2e1c3bbd6b915ac55488ed815de1e439351b2488)

Co-authored-by: Arjen Hiemstra <ahiemstra@heimr.nl>

M  +16   -13   src/pipewireproduce.cpp

https://invent.kde.org/plasma/kpipewire/-/commit/9f4c61d80bd01a92ebbcc0c89d7d7d12b9d12079