On Tue, 27 Aug 2019, Rémi Bernon wrote: [...]
=== debian10 (32 bit report) ===
user32: msg.c:5145: Test succeeded inside todo block: ShowWindow(SW_SHOWMINIMIZED):overlapped: marked "todo_wine" but succeeds
Report errors: user32:msg prints too much data (35221 bytes)
[...]
I don't see how this is related. Also, it looks like from the full logs that the test is actually failing but is reported as succeeding inside todo, which is weird.
There are two issues: * The "too much data" one is not related to your patch specifically. It's an error that gets added by the TestBot on tests that print too much data, such as user32:msg has been doing for a long time.
The issue there is that on Linux the WineTest results are already very close to the 1.5 MB limit. With over 600 tests that's about 2.5 KB / test. So tests that print over 32 KB are taking way more than their fair share and get identified as such in the hope that we at least not introduce new hogs and hopefully eventually fix the existing ones (hint, hint).
* The second issue is that if an ok() call succeeds in a todo_wine then that todo_wine should be removed. So the patch is wrong and needs to be fixed. Of course if the specific ok() call fails randomly then... I guess the test needs to be fixed again so back to square one. It does become a real problem when the failure depends on the Unix platform though.
This specific ShowWindow(SW_SHOWMINIMIZED) ok() call seems to fail pretty systematically and as such should have been treated as a preexisting failure. However it looks like a full WineTest run has not been done since the 23rd, which typically happens when the official WineTest.exe fails to build. Maybe that's why the failure was not detected as a preexisting one.
(Removing the TestBot's dependency on this external WineTest.exe build is on my todo list)
When testing on my side the user32 msg tests are triggering a crash in mutter, but work fine with openbox (and do not report any failure for this patch). Wouldn't it be better to use openbox - or any other WM that doesn't crash spuriously - for the automated regression tests?
The Debian TestBot VMs use fvwm precisely because neither the GNOME nor the KDE window managers are up to the task (they not only used to crash but also mishandled various test cases).
I don't see any evidence that fvwm crashed in the logs and the screenshot looks normal barring the tiny window in the top-left corner (but that might be a left-over from the test, maybe due to the failures?). I'm not a specialist on these things so maybe I missed the telltale signs.
Note that the screen being blank is normal, it's a very basic fvwm configuration. I guess it can be confusing and does make it harder to see if the window manager crashed. Maybe the TestBot should put up a window saying 'This screen intentionally left blank' ;-)