13 Jul
2022
13 Jul
'22
6:57 p.m.
On Wed Jul 13 18:53:36 2022 +0000, **** wrote:
Zebediah Figura replied on the mailing list:
On 7/13/22 13:29, Claire (@ClearlyClaire) wrote: > On Wed Jul 13 17:25:36 2022 +0000, **** wrote: >> Zebediah Figura replied on the mailing list: >> \`\`\` >> On 7/13/22 04:28, Claire (@ClearlyClaire) wrote: >>> On Tue Jul 12 23:34:52 2022 +0000, **** wrote: >>>> Marvin replied on the mailing list: >>>> \`\`\` >>>> Hi, >>>> It looks like your patch introduced the new failures shown below. >>>> Please investigate and fix them before resubmitting your patch. >>>> If they are not new, fixing them anyway would help a lot. Otherwise >>>> please ask for the known failures list to be updated. >>>> The tests also ran into some preexisting test failures. If you know how >>>> to fix them that would be helpful. See the TestBot job for the details: >>>> The full results can be found at: >>>> https://testbot.winehq.org/JobDetails.pl?Key=118863 >>>> Your paranoid android. >>>> === w7u_2qxl (32 bit report) === >>>> ntoskrnl.exe: >>>> ntoskrnl.c:1654: Test failed: got size 78 >>>> ntoskrnl.c:1655: Test failed: got container ID "{" >>>> === w7u_el (32 bit report) === >>>> ntoskrnl.exe: >>>> ntoskrnl.c:1654: Test failed: got size 78 >>>> ntoskrnl.c:1655: Test failed: got container ID "{" >>>> === w8 (32 bit report) === >>>> ntoskrnl.exe: >>>> ntoskrnl.c:1654: Test failed: got size 78 >>>> ntoskrnl.c:1655: Test failed: got container ID "{" >>>> === w1064_tsign (64 bit report) === >>>> ntoskrnl.exe: >>>> ntoskrnl.c:1654: Test failed: got size 78 >>>> ntoskrnl.c:1655: Test failed: got container ID "{" >>>> === debian11 (32 bit Hebrew:Israel report) === >>>> ntoskrnl.exe: >>>> driver_pnp.c:706: Test failed: Got 1 remove events. >>>> === debian11 (32 bit Hindi:India report) === >>>> ntoskrnl.exe: >>>> driver_pnp.c:706: Test failed: Got 1 remove events. >>>> \`\`\` >>> I do not understand those test failures. From what I understand, they >> are from running the test on certain Windows environments, but even >> then, I do not understand why `SetupDiGetDeviceInstanceIdA` would return >> a UTF-16 string as opposed to the ANSI string it is supposed to return. >> The >> [documentation](https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/irp-mn-query-id) >> says the response to `BusQueryContainerID` is a `REG_SZ` value to be >> stored to a `WCHAR` pointer, so I'm not sure what the issue would be. >>> >> Probably Windows is just broken in this respect. I'd either adjust the >> test (and implementation) to match, or use broken(). >> _______________________________________________ >> wine-gitlab mailing list -- wine-gitlab@winehq.org >> To unsubscribe send an email to wine-gitlab-leave@winehq.org >> \`\`\` > I wouldn't know how to match this behavior as it seems fairly inconsistent (it seems like 4 out of 23 windows test envs returned a UTF-16 string while all the others returned the expected ANSI string). Using `broken()`. > I think that's just because those machines are the only ones that are capable of running the ntoskrnl tests in the first place; the tests are skipped everywhere else. _______________________________________________ wine-gitlab mailing list -- wine-gitlab@winehq.org To unsubscribe send an email to wine-gitlab-leave@winehq.org
Oh, makes sense, I hadn't noticed the other envs skipped it. I added `broken` calls, but I can probably simplify the tests by just calling the widechar variant of the function if you prefer. I'm not sure how much sense replicating Windows' broken behavior would make, and the games I've seen actually use it use the widechar variant.