[Bug 53230] New: user32:win - test_activateapp() fails randomly with fvwm
https://bugs.winehq.org/show_bug.cgi?id=53230 Bug ID: 53230 Summary: user32:win - test_activateapp() fails randomly with fvwm Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- user32:win - test_activateapp() fails randomly with fvwm. The failures themselves change quite a bit from one run to the next, depending on where in the function the failures start. It looks a bit like a race condition between the test and the window manager. Here is a relatively complete set: win.c:10976: Test failed: Expected foreground window 0, got 01DE007C win.c:10982: Test failed: Expected foreground window 001A013C, got 01DE007C win.c:10992: Test failed: Expected foreground window 001A013C, got 00000000 win.c:10999: Test failed: Expected foreground window 001A013C, got 01DE007C win.c:11001: Test failed: GetActiveWindow() = 00000000 win.c:11001: Test failed: GetFocus() = 00000000 win.c:11003: Test failed: Received WM_ACTIVATEAPP(0), did not expect it. win.c:11011: Test failed: Expected foreground window 001A013C, got 00000000 win.c:11013: Test failed: GetActiveWindow() = 00000000 win.c:11013: Test failed: GetFocus() = 00000000 win.c:11021: Test failed: Received WM_ACTIVATEAPP(1), did not expect it. https://test.winehq.org/data/patterns.html#user32:win The failures don't seem to depend on the locale or bitness. However they only happen in the TestBot VMs which happen to run fvwm (with a specially curated configuration file) and don't happen on my box which runs KDE for instance. -- 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=53230 François Gouget <fgouget(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |source, testcase -- 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=53230 Rémi Bernon <rbernon(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rbernon(a)codeweavers.com --- Comment #1 from Rémi Bernon <rbernon(a)codeweavers.com> --- There's a race condition in user32 when multiple window activation messages are queued, without being processed, and are later processed in the wrong order because of recursive message processing. Then there's also a race condition with X11 window activation events, which are coming late and which are racing against normal user32 window activation logic by re-activating windows that already went through the activation logic once. This isn't going to be easy to fix as there's no way to tell X11 activation events that the result of a window being mapped or restored, from activation events that come from a user interaction. -- 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=53230 --- Comment #2 from François Gouget <fgouget(a)codeweavers.com> --- Here is a variant which sometimes happens alone and sometimes is followed by the original set of failures: win.c:10983: Test failed: GetForegroundWindow() = 00E80082 -- 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