On 1/31/22 18:24, Rémi Bernon wrote:
MK11 creates an alternate stack and sometimes throws an exception which gets incorrectly handled by a Wine exception handler, causing the game to crash.
Signed-off-by: Rémi Bernon rbernon@codeweavers.com
dlls/ntdll/signal_x86_64.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/dlls/ntdll/signal_x86_64.c b/dlls/ntdll/signal_x86_64.c index 7e77329363c..36985832e4a 100644 --- a/dlls/ntdll/signal_x86_64.c +++ b/dlls/ntdll/signal_x86_64.c @@ -463,7 +463,9 @@ static NTSTATUS call_stack_handlers( EXCEPTION_RECORD *rec, CONTEXT *orig_contex } } /* hack: call wine handlers registered in the tib list */
else while ((ULONG64)teb_frame < context.Rsp)
else while ((ULONG64)teb_frame < context.Rsp &&(ULONG64)teb_frame >= (ULONG64)NtCurrentTeb()->Tib.StackLimit &&(ULONG64)teb_frame <= (ULONG64)NtCurrentTeb()->Tib.StackBase)
The same change should in theory go to RtlUnwindEx() and RtlRestoreContext()?
Although now after thinking a bit more about it I don't quite understand how this is going to work when thread is switching stack. When switching stack on i386 where TIB handlers belong that involves switching Tib.ExceptionList as well (see, e. g., kernelbase/thread.c:SwitchToFiber(). If the stack is switched but the ExceptionList is not there will be a mix of frames between the two stacks in the Teb list, popping those frames probably won't work right after switching. Do you know how the game is switching stack? Maybe I am missing something but IMO without knowing some details on how the game is doing that the only real way to solve it is to get rid of the ExceptionList hack on x64 (which is possible to do but in a not particularly nice way in the absence of .seh handlers support in mingw).