https://bugs.kde.org/show_bug.cgi?id=527202

--- Comment #2 from Billy T <[email protected]> ---
Thank you, @desislav.lesov, for the analysis. I hit the same 0x200d on my
machine during additional testing, and your explanation of the uninitialized
Surface members matched what I found in the source. Your suggested fix works.

Here are my results, in case they help whoever picks this up.

The bug also appears with --plasma, so portal mode is not the trigger. I tested
krdpserver 6.8.0 with --plasma --mode RemoteAccess and Windows App on macOS.

To reproduce it on demand, set MALLOC_PERTURB_=85 and
GLIBC_TUNABLES=glibc.malloc.tcache_count=0. MALLOC_PERTURB_ by itself does
nothing here, because glibc recycles the 104-byte VideoStreamSurface through
its tcache without filling it. Turning the tcache off lets the perturb fill
every allocation with 0xAA.

Unfixed build: I added a log line at the top of destroySurface(). The first
call prints id=43690 (0xAAAA) and codecContextId=2863311530 (0xAAAAAAAA). The
client drops 9 ms later with ERRCONNECT_CONNECT_TRANSPORT_FAILED [0x0002000D]
after "rdpgfx_server_handle_messages: WTSVirtualChannelRead failed", and
Windows App shows 0x200d.

Fixed build: with your default initializers on the two members, three connect
and disconnect cycles in a row ran clean under the same settings.

--- a/src/VideoStreamSurface.h
+++ b/src/VideoStreamSurface.h
 struct Surface {
-    uint16_t id;
-    uint32_t codecContextId;
+    uint16_t id = 0;
+    uint32_t codecContextId = 0;
     QSize size;
 };

Without perturb, the first destroySurface() sees id=0 and the connection works.
A same-size test object in a standalone program read a stale 0x0007 from the
previous object with perturb alone, and 0xaaaa with both settings. That fits
the intermittent reports: a reused block holds either a stale id or zero,
depending on what ran before. For the same reason --plasma gives no workaround.
The heap contents decide whether a connection fails.

Thanks for tracking this down.

-- 
You are receiving this mail because:
You are watching all bug changes.

Reply via email to