[Bug 57926] New: wine-mono wpfclipboard test can fail if a clipboard manager is running
https://bugs.winehq.org/show_bug.cgi?id=57926 Bug ID: 57926 Summary: wine-mono wpfclipboard test can fail if a clipboard manager is running Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ole32 Assignee: wine-bugs(a)winehq.org Reporter: madewokherd(a)gmail.com Distribution: --- This is an odd one. I've been seeing random failures in the wpfclipboard test (https://gitlab.winehq.org/mono/wine-mono/-/blob/main/tools/tests/wpfclipboar...). This is caused by fcitx requesting the clipboard at a bad time, presumably after it changes so it can track the history. I tried enabling clipboard history on Windows, and it didn't break the same test, so presumably this is a Wine bug of some variety. An ole,clipboard log first shows FCITX requesting the clipboard contents: 00a4:trace:clipboard:X11DRV_SelectionRequest got request on 5200003 for selection "CLIPBOARD" target "UTF8_STRING" win 1600000 prop "FCITX_X11_SEL_CLIPBOARD" 00a4:trace:clipboard:NtUserOpenClipboard 0x10030 00a4:trace:clipboard:NtUserGetClipboardData CF_UNICODETEXT sending WM_RENDERFORMAT to 0x10058 followed by WPF repeatedly trying to call OleFlushClipboard like this: 0140:trace:ole:OleFlushClipboard () 0140:trace:clipboard:NtUserOpenClipboard 0x10058 (WPF will retry this in a loop, 10 times with 0.1 second delay, until it succeeds: https://gitlab.winehq.org/mono/wpf/-/blob/wine-mono/src/Microsoft.DotNet.Wpf...) And finally an exception: [ERROR] FATAL UNHANDLED EXCEPTION: System.Runtime.InteropServices.COMException (0x800401D0) at System.Runtime.InteropServices.Marshal.ThrowExceptionForHR (System.Int32 errorCode, System.IntPtr errorInfo) [0x0000b] in <9023c5f6a7ee423aa752c291dcce5a37>:0 at MS.Internal.SecurityHelper.ThrowExceptionForHR (System.Int32 hr) [0x00008] in <a958f5aec4f044f89438543f2bcdc7c8>:0 at System.Windows.Clipboard.Flush () [0x0002c] in <a958f5aec4f044f89438543f2bcdc7c8>:0 at System.Windows.Clipboard.CriticalSetDataObject (System.Object data, System.Boolean copy) [0x000a9] in <a958f5aec4f044f89438543f2bcdc7c8>:0 at System.Windows.Clipboard.SetDataObject (System.Object data, System.Boolean copy) [0x00001] in <a958f5aec4f044f89438543f2bcdc7c8>:0 at System.Windows.Clipboard.SetDataInternal (System.String format, System.Object data) [0x00025] in <a958f5aec4f044f89438543f2bcdc7c8>:0 at System.Windows.Clipboard.SetText (System.String text, System.Windows.TextDataFormat format) [0x0003f] in <a958f5aec4f044f89438543f2bcdc7c8>:0 at System.Windows.Clipboard.SetText (System.String text) [0x00015] in <a958f5aec4f044f89438543f2bcdc7c8>:0 This error code is CLIPBRD_E_CANT_OPEN, according to a quick search. Importantly, WPF's loop doesn't handle window messages. The clipboard is open because explorer is waiting for WPF to respond to WM_RENDERFORMAT, but WPF can't do that because it's in the Flush loop. I'm not sure how this is supposed to work. The Flush loop in WPF is the same in modern .NET, so that can be assumed to work on Windows without running a message loop. (We could theoretically work around it in Wine Mono, but that wouldn't help with modern .NET. I also don't expect this failure mode to be common in practice.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57926 Esme Povirk <madewokherd(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |madewokherd(a)gmail.com Keywords| |download, source, testcase URL| |https://dl.winehq.org/wine/ | |wine-mono/9.4.0/wine-mono-9 | |.4.0-tests.zip -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57926 --- Comment #1 from Esme Povirk <madewokherd(a)gmail.com> --- I also tried running CopyQ, just in case Windows' builtin clipboard history feature is special somehow. Still couldn't reproduce the error on Windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=57926 --- Comment #2 from Esme Povirk <madewokherd(a)gmail.com> --- Actually, I don't think this is caused by the wpfclipboard test doing weird things. This appears to be entirely contained in WPF's CriticalSetDataObject method, which would mean it's not unlikely for this to happen in normal use. And it seems WPF is making this more likely by inserting a 0.1 second Sleep call between setting the clipboard and calling OleFlushClipboard. This makes it even less likely that it's broken in this way on Windows. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla