TestBot job 94484 results: [PATCH 2/2] ole32: Do not link OLE clipboard object lifecycle to OLE initialization state.

[Francois Gouget]

On Fri, 23 Jul 2021, Paul Gofman wrote:

> On 7/23/21 21:18, Marvin wrote:
> >
> > === debiant2 (64 bit WoW report) ===
> >
> > ole32:
> > clipboard.c:1067: Test failed: OleIsCurrentClipboard returned 0
> > clipboard.c:1135: Test failed: 1 WM_DRAWCLIPBOARD received
> 
> Doesn't seem related to my patches, but I could reproduce this and other
> random failures locally (both with and without my patches). One sort of
> such failures I looked into (I suspect that relates to all of them
> actually) was due to the race between the test working with the
> clipboard and winex11.drv clipboard operation from explorer process
> (like, opening clipboard from X11DRV_SelectionRequest()). That selection
> request seems to be triggered by window creation and thus interferes
> with the test. I haven't debug that in details yet. Is it maybe a known
> issue?

My current understanding on this is that X11DRV_SelectionRequest() 
should only interfere with the clipboard if the desktop environment has 
a nosy clipboard manager that wants to know what's in the clipboard at 
all times.

debiant2 is running fvwm and thus should not have any such issue.

This is based on my analysis of user32:clipboard which was failing on my 
KDE desktop for this reason but did not fail on the TestBot VMs. 
user32:clipboard now has "counter-measures" which allow it to succeed 
everywhere. I have been distracted with other issues so I have not yet 
had time to look into the other clipboard tests. I suspect they have 
similar issues but since this failure happens on debiant2 it may be 
different.

When you say you can reproduce the issue, is that in your regular 
desktop environment? Is it KDE?


-- 
Francois Gouget <fgouget at codeweavers.com>