[Bug 59947] New: i386 unwinding testcases fail nondeterministically
http://bugs.winehq.org/show_bug.cgi?id=59947 Bug ID: 59947 Summary: i386 unwinding testcases fail nondeterministically Product: Wine Version: 11.12 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@list.winehq.org Reporter: martin@martin.st Distribution: --- Created attachment 81315 --> http://bugs.winehq.org/attachment.cgi?id=81315 Test binary 1 Some unwinding testcases, built for i386, fail nondeterministically. These testcases are built from https://github.com/microsoft/compiler-tests/blob/master/seh/seh0023.c, seh0024.c and seh0025.c, built with "cl -MD seh0023.c". They mostly run fine, but some times, they fail with an error like this: 0160:err:virtual:virtual_setup_exception stack overflow 1088 bytes addr 0x7e3f432b stack 0x410bc0 (0x410000-0x411000-0x510000) I test it with a command setup like this: fail=; while [ -z "$fail" ]; do for i in seh????-md.exe; do echo $i; wine $i || { fail=1; break; }; done; done They mostly fail after 5-50 attempts. I see the same kind of errors both with PE and ELF builds of Wine, both with new wow64 and the old kind, built with both GCC and Clang, mingw mode and MSVC mode. (I haven't tested a setup with a full 32 bit wineserver, but they all run with a 64 bit wineserver.) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59947 --- Comment #1 from Martin Storsjö <martin@martin.st> --- Created attachment 81316 --> http://bugs.winehq.org/attachment.cgi?id=81316 Test binary 2 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59947 --- Comment #2 from Martin Storsjö <martin@martin.st> --- Created attachment 81317 --> http://bugs.winehq.org/attachment.cgi?id=81317 Test binary 3 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59947 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, source, testcase -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=59947 Bernhard Übelacker <bernhardu@mailbox.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bernhardu@mailbox.org --- Comment #3 from Bernhard Übelacker <bernhardu@mailbox.org> --- Created attachment 81383 --> http://bugs.winehq.org/attachment.cgi?id=81383 debugging2.txt Hello, I tried if I could reproduce the issue here and if I could collect some details. And it showed also inside rr-debugger. In my tests I hit msvcrt_local_unwind4 twice. The first time with, as far as I can see, valid frame->scopetable and cookie pointer. But the second call to msvcrt_local_unwind4 appears to have the same frame->scopetable but a different cookie. Therefore the function local pointer scopetable seems to contain an invalid address. In the good case the address is currently not mapped, therefore msvcrt_local_unwind4 receives a SIGSEGV, which somehow makes the executable succeed. In the bad case the address is currently mapped, in my case to kernelbase.dll, therefore a recursive exception chain is entered, which leads to the "virtual_setup_exception stack overflow", and gets visible as faulting return value from the executable. Trying to find out where this "wrong" security cookie originates from, I found it is from this assignment "jmp->Cookie = MSVCRT_JMP_MAGIC;" in __regs__setjmp3. Also it looks like a pointer to the real cookie is given in the va_list and gets stored in jmp->UnwindData[0]. That led me to following modification, which seems to work, and gave me no fault in 50000 iterations. (only seh0023-md.exe) What do you think? dlls/msvcrt/except_i386.c @@ -865,7 +865,10 @@ void __stdcall _seh_longjmp_unwind(_JUMP_BUFFER *jmp) */ void __stdcall _seh_longjmp_unwind4(_JUMP_BUFFER *jmp) { - msvcrt_local_unwind4( (ULONG *)&jmp->Cookie, (MSVCRT_EXCEPTION_FRAME *)jmp->Registration, + ULONG* cookie = (ULONG *)&jmp->Cookie; + if (*cookie == MSVCRT_JMP_MAGIC) + cookie = (ULONG*)jmp->UnwindData[0]; + msvcrt_local_unwind4( cookie, (MSVCRT_EXCEPTION_FRAME *)jmp->Registration, jmp->TryLevel, (void *)jmp->Ebp ); } -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla