On Thu Mar 9 18:05:24 2023 +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=130422
> Your paranoid android.
> === w7u_2qxl (32 bit report) ===
> kernel32:
> loader.c:2324: Test failed: wrong tls data 'hello world' at 00C54600
> === w7u_adm (32 bit report) ===
> kernel32:
> loader.c:2324: Test failed: wrong tls data 'hello world' at 00BE4600
> === w7u_el (32 bit report) ===
> kernel32:
> loader.c:2324: Test failed: wrong tls data 'hello world' at 00C546A0
> === w7pro64 (64 bit report) ===
> kernel32:
> loader.c:2324: Test failed: wrong tls data 'hello world' at 0000000000D405F0
> ```
This is a regression in the tests when running on Windows 7.
That should have been grounds for rejection of the merge request!
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/2361#note_26599
Without this patch the process will silently die.
I managed to trigger this while trying to trace Child of Light with Renderdoc,
the latter of which crashed in its own "TargetControlServerThread".
This, confusingly, manifested in the game restarting itself without the Ubisoft
overlay; apparently the game or one of its launchers was capable of recognizing
when the process had died and restarting it, but would not try to inject the
overlay a second time. I have not investigated the cause of the crash; it is not
unlikely that it resulted from the overlay injection (despite the fact that that
should only directly affect PE code.)
--
v4: ntdll: Print an error if we receive a signal not on the signal stack.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2126
And begin cleanup of several functions in preparation for their implementation. This only reverse the control flow to use early return (and cleanup variable names and traces as it's touching entire functions anyway), so that later changes wrt IME loading / freeing would be simpler.
--
v2: imm32: Reorder control flow in ImmGetConversionListW.
imm32: Reorder control flow in ImmGetConversionListA.
imm32: Reorder control flow in ImmEscapeW.
imm32: Reorder control flow in ImmEscapeA.
imm32: Reorder control flow in ImmEnumRegisterWordW.
imm32: Reorder control flow in ImmEnumRegisterWordA.
imm32: Reorder control flow in ImmConfigureIMEW.
imm32: Reorder control flow in ImmConfigureIMEA.
imm32: Rename ImmHkl to struct ime.
imm32/tests: Test undocumented ImmLoadIME / ImmFreeLayout.
imm32: Implement stubs for ImmFreeLayout and ImmLoadIME.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2354
This series intent is to let winedbg (and dbghelp) load the 64bit PE modules
of a wow64 debuggee.
At this stage, all debug info of all modules (PE and ELF) are properly loaded
(and displayed with 'info wow share' command).
Breakpoint and backtrace in 64bit code of a wow64 debuggee are not available.
The serie contains:
- extension of tests to show that 64bit load dll events are generated for
a wow64 debuggee (for a 64bit debugger, not for a 32bit one)
- change for adapting filtering of events
I opted for doing it in ntdll and passing the machine of the mapping in
request's reply. Please advisde if you'd prefer another approach.
--
v2: server: Generate dll events for 64bit DLLs in Wow64.
kernel32/tests: Extend the tests for load/unload debug events on Wow64.
https://gitlab.winehq.org/wine/wine/-/merge_requests/2240