[Bug 51234] New: user32:clipboard test_ClipboardOwner() has a race condition with clipboard managers
WineHQ Bugzilla
wine-bugs at winehq.org
Mon Jun 7 12:24:34 CDT 2021
https://bugs.winehq.org/show_bug.cgi?id=51234
Bug ID: 51234
Summary: user32:clipboard test_ClipboardOwner() has a race
condition with clipboard managers
Product: Wine
Version: 6.8
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: user32
Assignee: wine-bugs at winehq.org
Reporter: fgouget at codeweavers.com
Distribution: ---
test_ClipboardOwner() has a race condition with clipboard managers that causes
this set of failures:
clipboard.c:404: Test failed: SetClipboardData succeeded
clipboard.c:406: Test failed: wrong error 3735928559
clipboard.c:407: Test failed: SetClipboardData succeeded
Fortunately(?) this failure is pretty rare.
What happens is this:
* test_ClipboardOwner() does this:
OpenClibpoard(NULL)
EmptyClipboard() // take ownership
CloseClipboard()
* Then the clipboard manager starts checking the content of the clipboard:
OpenClipboard(manager_hwnd)
...
* And then the next test_ClipboardOwner() test happens:
SetClipboardData(CF_WAVE, ...)
ok(GetLastError() == ERROR_CLIPBOARD_NOT_OPEN, ...)
ok(!IsClipboardFormatAvailable(CF_WAVE), ...
Because test_ClipboardOwner() opened the clipboard with a NULL windows handle,
EmptyClipboard() used that as the clipboard owner. But when the owner is NULL a
process can place data in the clipboard as long as any process opened it. This
is actually the whole point of the run_process("set_clipboard_data 4") test.
So the problem is that user32:clipboard assumes that no other process is going
to open the clipboard after it called CloseClipboard(). Yet that's precisely
when clipboard manager would receive a WM_CLIPBOARDUPDATE message and open it.
--
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.
More information about the wine-bugs
mailing list