On 2020-07-03 15:48, Rémi Bernon wrote:
On 2020-07-03 15:32, Francois Gouget wrote:
On Fri, 3 Jul 2020, Rémi Bernon wrote: [...]
Ah indeed, I thought I could add more arguments to run them all.
The monitor test causes a Xephyr segmentation fault locally, but the msg test seems to run fine. I wonder if it could be snowballing from the monitor test.
I don't see X error messages in the "full task log". But if X segfaulted directly that would probably not be visible there.
I never tested it but if X segfaults I suspect we'd get back to the chooser which should reconnect the default user after the standard timeout (<30 seconds) and the tests are likely to continue running in the meantime. It's possible they could be stuck while X is restarting which could explain the string of timeouts.
It may be possible to test for this condition by starting an independent windows process displaying a window in an early test (CreateProcess("clock.exe")?) and checking the final screenshot to see if that window is still there.
I cancelled the remaining tests as it was taking way too long to timeout. I'm also investigating the monitor test, as the other tests run fine separately (at least msg, as shown here: https://testbot.winehq.org/JobDetails.pl?Key=74749). My local Xephyr crash seems actually unrelated (sadly).
It looks like that applying the mode changes by calling
ChangeDisplaySettingsExA(NULL ...)
sometimes takes an unusually long time, up to ~100s for a single mode change for instance, as shown here:
https://testbot.winehq.org/JobDetails.pl?Key=74774&f101=win32.report#k10...
With all the modes being iterated, it's no wonder that it ends up timing out. I think that it may be possible that the timeout then causes additional issues, if the process is killed during the mode change?