This MR fixes this random failure: http://test.winehq.org/data/126363ea5f9056449e8bd22cc69b51bd2d7dd9aa/linux_…
It happens mostly in d3d9, but if you try hard enough you can see it on d3d8 too.
There are more random failures in test_window_position that I have seen when running on an actual display but not in a dummy X server or Xephyr. One failure mode is that we lose focus in the initial create_device and minimize ourselves. This particular problem is specific to focus follows mouse. Another is that fvwm seems to place the window slightly offscreen, maybe shifted by the size of the window decoration. I am still looking into those issues.
Unrelated to test_windoow_position, there is at least one more random failure in test_wndproc (Test failed: Expected message 0x46 for window 0, but didn't receive it, i=0.), so expect more fvwm3 related MRs after this one...
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3778
In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same
table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem.
Visual Studio 2019 deadlock on start without this.
I'm not sure how to test this properly.
Also add debug info for this critical section so it show a significant name in the log.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
v2: ole32: Add debug info to RunningObjectTable critical section
ole32: Leave the RunningObjectTable Critical Section before umarshalling object
https://gitlab.winehq.org/wine/wine/-/merge_requests/3372
In certain circumstances unmarshalling an object stream from the RunningObjectTable can cause the unmarshalling routines to interrogate the same
table (maybe to resolve a dependant object?) in a different thread causing a deadlock while getting the critical section lock. Leaving the Critical Section before unmarshalling the object stream solve this problem.
Visual Studio 2019 deadlock on start without this.
I'm not sure how to test this properly.
Signed-off-by: Lorenzo Ferrillo <lorenzofersteam(a)live.it>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3372