testbot final screenshot (Re: [PATCH] comdlg32: Avoid crash in RemoveControlItem.)

[Bernhard Übelacker]

Am 11.12.21 um 11:26 schrieb Bernhard Übelacker:
> Am 10.12.21 um 16:42 schrieb Francois Gouget:
>> On Fri, 10 Dec 2021, Bernhard Übelacker wrote:
>>
>>> Hello Francois,
>>> I tried to submit today this patch, unfortunately it timed out at
>>> each Windows 7 and 10 VMs.
>>>
>>> It times out also with a patch that should not change behaviour
>>> when manually submitting.
>>> E.g. https://testbot.winehq.org/GetFile.pl?JobKey=103828
>>
>> You should be able to diagnose that by checking:
>>
>>    Timestamp traces (WINETEST_TIME)
>> and/or
>>    Report successful tests (WINETEST_REPORT_SUCCESS)
>>
>>
>>> I assume in my case winetest detects the runtime of more than 120
>>> seconds, terminates the child process and ends itself,
>>> then the screenshot is taken?
>>
>> Usually yes. Technically there's a bit of a race between the timeout in
>> Winetest.exe and the process monitoring the task on the TestBot server.
>> But normally Winetest.exe is supposed to time out first.
>>
>> It looks like the 'stack trace' of the test getting stuck is something
>> like this:
>>
>> itemdlg.c:1530:9.359 Test succeeded  // test_filename()
>> itemdlg.c:102:9.406 Test succeeded   // get_hwnd_from_ifiledialog()
>> itemdlg.c:221:9.422 Test succeeded   // 
>> IFileDialogEvents_fnOnFolderChange()
>>
>> https://testbot.winehq.org/JobDetails.pl?Key=103851
>>
>> It may be necessary to add some more traces to pinpoint exactly where
>> the test gets stuck.
>>
>>
>>> Is there a way to get the screenshot before the timeout of 
>>> winetest.exe is
>>> reached? E.g. a possibility to reduce some kind of "outer" timeout?
>>
>> There's a plan to take screenshots at a to-be-determined regular
>> interval. Some progress has been made on it but there's a dozen other
>> things to improve on the TestBot and at some point it fell by the
>> wayside :-(
>>
>> https://bugs.winehq.org/show_bug.cgi?id=44709
>>
> 
> 
> Hello Francois,
> thanks for the pointers.
> I got an idea to run the test in a detached process,
> so it would not get killed...
> 
> And it seems it worked:
> https://testbot.winehq.org/JobDetails.pl?Key=103923
> 
> The screenshot shows:
>      Open
>      winetest
>      File not found.
>      Check the file name and try again.
>      OK
> 
> 
> And the last lines of the test output:
>      itemdlg.c:1530:7.281 Test succeeded
>      itemdlg.c:99:7.360 Test succeeded
>      itemdlg.c:102:7.360 Test succeeded
>      itemdlg.c:213:7.360 Test succeeded
>      itemdlg.c:216:7.375 Test succeeded
>      itemdlg.c:221:7.375 Test succeeded
>      1530:itemdlg:10.015 0 tests executed (0 marked as todo, 0 
> failures), 0 skipped.
>      comdlg32:itemdlg:1530 done (0) in 10s
> 
> The last two lines seem to be from the "parent" process,
> the lines above from the detached "child" process.
> 
> So it looks kind of after the "OK command" in line 220
> the dialog is not operating in the directory it got told to ...
> 
> 
> Attached the patch if it might be of help for future cases
> (the Sleep might need to get adjusted).
> 
> Just another small note:
> I first tested this against the w7u_2qxl (103921),
> but there the screen stays empty, not even a taskbar.
> So I wonder if the screenshot get taken from the second screen.
> 
> Thanks and
> Kind regards,
> Bernhard

Hello Francois,
just a small addition.
This hang with this "File not found" message
seems to be caused by the test started with current directory in
public documents, where also the test files get generated.
Therefore cannot find them in my documents.

This patch changes the current directory if found to be
in public documents: https://source.winehq.org/patches/data/222000

This difference is also visible in my initial job 103829 in the task log,
where failing runs got started from public documents.

Kind regards,
Bernhard