[Bug]: VRDE mouse input stalls ~5 seconds after Ctrl+C in headless Linux/X11 guest (7.2.20)

The payload points to the Shared Clipboard source that declares SHCL_TIMEOUT_DEFAULT_MS as the suspected blocking path, with VRDE input dispatch in VBoxHeadless as the other side of the question. No file paths are given, so first locate those symbols in the VirtualBox source tree and reproduce the stall with a synthetic xclip test. Done would mean identifying the call that blocks input delivery, which is root-cause work in a hypervisor codebase rather than a small change.

Version

7.2.20

Host OS Type

Windows

Host OS name + version

Windows 11 Pro 26H2, x64 (VirtualBox host)

Host Architecture

x86

Guest OS Type

Linux

Guest Architecture

x86

Guest OS name + version

Linux Mint 22.3, Cinnamon on X11 (guest Linux kernel 6.8.0-146-generic; reproduced also on a separate Linux Mint test VM with kernel 7.0.0-38-generic)

Component

RDP

What happened?

VirtualBox 7.2.20 (Windows 11 Pro 26H2 host, matching Extension Pack and Guest Additions) with a Linux Mint/Cinnamon X11 guest in VBoxHeadless mode, accessed through direct VirtualBox VRDE using Windows MSTSC (not xrdp). After Ctrl+C inside Linux, the client mouse pointer still moves and the Linux desktop continues rendering, but guest clicks, text selection, hover, dragging and paste do not respond for about FIVE SECONDS.

Six manual Ctrl+C reproductions were instrumented: in the six five-second intervals after Windows clipboard announcements, Windows recorded 98 cursor-motion samples while guest X11 recorded just 1; Linux input resumed after ~5.11 s (median, clocks aligned approximately). GTK timers continued updating without >300 ms gaps. This occurs with one RDP client and was reproduced on a second Linux Mint test VM with a different kernel.

Expected: clipboard synchronization must not block guest input. Disabling Shared Clipboard or RDP clipboard redirection removes the mouse stall but loses clipboard transfer. Rebooting/upgrading to matching 7.2.20 did not cure it. An additional VRDE client also coincided with temporary guest-to-Windows clipboard loss; after reboot and returning to one client, transfer recovered while the input stall remained.

The cause within VirtualBox is not proven. Detailed A/B findings and upstream code references are in the sanitized TXT report (to be attached manually); no private VBox.log or clipboard payload is included.

ORACLE_VRDE_GITHUB_ISSUE_V63_PUBLIC.md

How can we reproduce this?

1. On a Windows 11 host, start a Linux Mint/Cinnamon X11 guest using VBoxHeadless, with Oracle Extension Pack VRDE enabled and VM Shared Clipboard set to Bidirectional.
2. On a separate Windows system, connect to the VM's VirtualBox VRDE server using MSTSC with its clipboard redirection enabled. Do not use xrdp in the guest.
3. Select innocuous plain text in a Linux application and press Ctrl+C.
4. Immediately move the Windows RDP cursor across other Linux windows and try to click, select, hover, or drag a window.
5. The client-side pointer moves, but the guest ignores those interactions for roughly five seconds, then starts responding again. Repeat with different text selections.

Instrumented reproduction (six manual copies)

During a 90-second user-operated test, three independent read-only probes monitored (1) Windows client's GetCursorPos and GetClipboardSequenceNumber, (2) guest X11 XQueryPointer and mouse button mask, and (3) a small GTK test panel's event callbacks/heartbeat. They did not collect clipboard contents, keystrokes, screen images, usernames, or VM IDs.

Clipboard update	Windows pointer movement samples during next 5 s	Linux X11 pointer movement samples during next 5 s	First subsequent guest movement (s)
1	17	0	5.117
2	9	1	5.098
3	13	0	5.121
4	16	0	5.019
5	11	0	5.051
6	32	0	5.110

Across these six five-second windows, 98 Windows pointer-motion samples versus just 1 Linux X11 pointer-motion sample and 0 guest mouse-button-mask changes. Median delay until Linux pointer movement resumed was approximately 5.11 s.

At the same time the independent GTK panel executed 870 timer callbacks (roughly 100 ms each, no gap over 300 ms) and later received delayed mouse enter/click events. Guest X11 query times remained short (maximum 9.245 ms for XQueryPointer, 4.12 ms for XGetSelectionOwner). This points to VRDE-to-guest input delivery stalling, rather than a global X11/GTK/video freeze.

Timing limitation: Linux and Windows system clocks differed by approximately 1.87 s, estimated using SSH round-trip timing after the capture. The offset adjustment has an estimated ~0.15–0.25 s uncertainty. Windows clipboard sequence updates mark clipboard announcements, not the precise physical instant of Ctrl+C. The six roughly five-second intervals are nonetheless reproducible.

Isolation / troubleshooting already attempted

• Disable VM Shared Clipboard: no input stall, but remote clipboard transfer is lost.
• Disable RDP client clipboard redirection: no input stall, but transfer is lost.
• Guest-to-host only mode, disabling drag-and-drop or clipboard file transfers: does not fix the stall.
• Start the same VM with GUI/Qt instead of VBoxHeadless: input stall disappears, but Linux guest → remote Windows VRDE client clipboard copy still does not work. The local Windows host clipboard is a different endpoint and was not independently validated.
• Reboot both Windows host and Linux guest: no improvement.
• Upgrade all three components from 7.2.18 to matching 7.2.20: no improvement.
• Disconnect an additional RDP session to the Windows VirtualBox host: no improvement.
• Separate RustDesk session: input and clipboard work normally.
  The symptom was also observed earlier with FreeRDP and Apache Guacamole clients.

Suspected area (not confirmed)

VirtualBox's Shared Clipboard source declares SHCL_TIMEOUT_DEFAULT_MS (five seconds). An earlier separate synthetic xclip test produced seven Shared Clipboard ... VERR_TIMEOUT events in the host log spaced approximately five to six seconds apart. A different GUI Ctrl+C test did not produce those error lines, so these synthetic-test timeouts are not proof of the exact blocking call during manual copying.

Could VRDE mouse-input dispatch be held up by a synchronous Shared Clipboard/HGCM format/data-request wait, delayed rendering, or contention in VBoxHeadless? Guidance on the most relevant event/request IDs or trace groups would be appreciated.

Related but apparently distinct reports: #568, #858 and historical headless VRDP clipboard ticket #10057.

Did you upload all of your necessary log files, screenshots, etc.?

• Yes, I've uploaded all pertinent files to this issue.