Re: [lmi] A probably-inconsequential 'wine' error

[Greg Chicares]

On 11/11/21 9:29 PM, Vadim Zeitlin wrote:
> On Thu, 11 Nov 2021 17:06:43 +0000 Greg Chicares <gchicares@sbcglobal.net> 
> wrote:
> 
> GC> While testing an intended migration from
> GC>   debian 'bullseye', wine-4.0.3 (Debian 4.0.3-1), to
> GC>   debian 'bookworm', wine-5.0.3 (Debian 5.0.3-3)
> GC> I saw this error message with 'bullseye':
> GC> 
> GC>   System test:
> GC>   0020:err:clipboard:convert_selection Timed out waiting for 
> SelectionNotify event
> GC>   All 1485 files match.
> GC> 
> GC> I reran that test in isolation, and observed no such error message,
> GC> so it appears to be irreproducible.
> 
>  FWIW the message is given only if the code fails to get the clipboard
> contents after trying for 0.5 seconds, so it's timing-dependent and should
> have higher chances of happening on a busy system.

Indeed, the original report pertains to a period of time when I was
doing other work on this machine; and the subsequent failure to
reproduce, to a different time when I was doing almost nothing else.

> GC> Everything else in 'nychthemeral_test.sh' seemed to work exactly
> GC> the same in both chroots.
> GC> 
> GC> This error message seems inconsequential because 'make system_test'
> GC> succeeds ("All 1485 files match." in both chroots).
> GC> 
> GC> It seems weird because IIRC the 'system_test' target wouldn't use
> GC> the clipboard at all--it uses the 'lmi_cli_shared$(EXEEXT)' binary,
> GC> which doesn't link wx, and all lmi's use of the clipboard goes
> GC> through wx.
> 
>  I agree that this is quite strange, as this message definitely comes from
> the X11 clipboard code (see dlls/winex11.drv/clipboard.c) and can only
> happen when the program is trying to retrieve the current clipboard
> selection, and nothing in lmi_cli_shared code should be able to do it. My
> only explanation is that some other part of Wine is trying to do it, but I
> could find any code doing this susceptible to be called by lmi neither.

That's interesting. Let me also mention that
 - I was simultaneously running a different version of 'wine' in a
   different chroot (but saw no such error messages there); and
 - the X clipboard sometimes seems to be taken over by gremlins, e.g.:
     https://lists.nongnu.org/archive/html/lmi/2017-11/msg00000.html
   perhaps due to the interplay among X, 'konsole' with all its
   underlying KDE stuff, 'gnome', 'dbus', and 'wine'.

In fact, over the last year or so, with frequent upgrades of debian
versions on my base system and in chroots, the X clipboard seems to
have become less stable. Pasting from a 'konsole' terminal into
'firefox' often fails. Pasting into 'vim' first (from anywhere),
and then from 'vim' (to anywhere), using the '"+' vim register,
always seems to work.

> I
> probably should be able to really answer this question if I run the tests
> under debugger and put a breakpoint on the function where the error message
> is given, but I'm not sure if it's worth doing this

I agree: that doesn't seem worthwhile.

>  BTW, speaking about clipboard code, it seems there hasn't been any updates
> to handling Ctrl-C in Wine message boxes and neither my patch (which I
> wrote for lmi benefit and submitted in January 2020) nor the alternative
> patch has been merged into Wine, although the other patch is in
> wine-staging, see https://bugs.winehq.org/show_bug.cgi?id=17205

I can confirm that Ctrl-C does not exhibit the desired behavior
in wine-5.0.3 . I'm not inclined to invest time in experimenting
with 'wine-staging' or with whatever variety of 'wine' is in
debian 'sid', because 'wine' works well enough on crucial tasks.