On 4/16/20 9:38 PM, Marvin wrote:
Hi,
While running your changed tests, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check?
Full results can be found at: https://testbot.winehq.org/JobDetails.pl?Key=69857
Your paranoid android.
=== debiant (32 bit report) ===
qcap: filewriter.c:30: Test failed: Got hr 0x80040154. Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x004134ee).
Report validation errors: qcap:filewriter crashed (c0000005)
=== debiant (32 bit French report) ===
qcap: filewriter.c:30: Test failed: Got hr 0x80040154. Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x004134ee).
Report validation errors: qcap:filewriter crashed (c0000005)
=== debiant (32 bit Japanese:Japan report) ===
qcap: filewriter.c:30: Test failed: Got hr 0x80040154. Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x004134ee).
Report validation errors: qcap:filewriter crashed (c0000005)
=== debiant (32 bit Chinese:China report) ===
qcap: filewriter.c:30: Test failed: Got hr 0x80040154. Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x004134ee).
Report validation errors: qcap:filewriter crashed (c0000005)
=== debiant (32 bit WoW report) ===
qcap: filewriter.c:30: Test failed: Got hr 0x80040154. Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x004134ee).
Report validation errors: qcap:filewriter crashed (c0000005)
=== debiant (64 bit WoW report) ===
qcap: filewriter.c:30: Test failed: Got hr 0x80040154. Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x004134ee).
Report validation errors: qcap:filewriter crashed (c0000005)
This crash is a direct consequence of the testbot not updating the prefix; the test passes for me with a manual update.
In general I have to wonder if there's something more we can do to detect wineprefix updates, both for the sake of the testbot and for end users. As far as I know we only can detect an update if wine.inf gets touched, but other things should trigger an update as well, such as:
* a DLL/program getting added * a COM class being added to IDL-generated registry scripts * changes to WINE_REGISTRY resources * changes to DllRegisterServer(), for DLLs that need it manually called
The first three aren't too difficult to automatically detect, but the last one seems considerably more difficult. Still, implementing automatic detection for the first three at least seems like a good idea? I figure it's easiest to work it into the build system, though that might end up being pretty tricky.