-
Notifications
You must be signed in to change notification settings - Fork 11.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CrashRecoveryTest fails when built with clang-cl on 32-bit windows #44042
Comments
Bisection points to this change: commit a1f1699
llvm/include/llvm/Support/CrashRecoveryContext.h | 8 +++ But since the test passes when built with MSVC, I'm guessing the problem is really in clang's SEH support? Maybe something regressed there, and this change uncovered it? Also it's interesting that it seems to work in 64-bit builds but not 32-bit. |
Would you have a chance to try using VEH instead? https://github.com/llvm/llvm-project/blob/master/llvm/lib/Support/CrashRecoveryContext.cpp#L177 Change to #if defined(_MSC_VER) && !defined(clang) |
It seems we fail to catch the exception. And it seems the problem is the GetExceptionCode() call in the exception handler. If I comment out that, we catch the exceptions successfully (but the test doesn't pass because we don't set RetCode correctly):
I could try, but we want SEH to work too :-) |
We also saw this test failing on our internal Windows build bot after the change in comment 1. |
Here's a reduced repro: #include <excpt.h> static void nullDeref() { *(volatile int *)0x10 = 0; } static bool InvokeFunctionCall(void (*Fn)(void), bool DumpStackAndCleanup, int &RetCode) { int main() { C:\src\llvm.monorepo\build.32_2019>bin\clang-cl /O2 \src\tmp\a.cc && a.exe Reid, when you have a moment, can you take a look? |
I've pushed 31e0769 to unbreak the test for now, but I hope we can get the SEH problem fixed before the 10 release. |
There is a second crash in the __except block because a load is hoisted above an instruction that sets up EBP: LBB2_1: # %__except.ret Some pass needs to know that it can't hoist a reload from a frame index above these instructions that re-establish the stack frame. |
The register allocator inserts this load: *** IR Dump After Greedy Register Allocator ***:Machine code for function ?InvokeFunctionCall@@YA_NP6AXXZ_NAAH@Z: NoPHIs, TracksLiveness... 304B bb.1.__except.ret (landing-pad): 308B %13:gr32 = MOV32rm %fixed-stack.0, 1, $noreg, 0, $noreg :: (load 4 from %fixed-stack.0) We need a better way to "glue" EH_RESTORE to the top of the BB, or instead insert EH_RESTORE later. |
This actually repros in clang 4.0 according to godbolt, so we've had this bug since forever. |
Pending fix: https://reviews.llvm.org/D73752 |
I can see this test fail on our internal Windows buildbot even with the fix in https://reviews.llvm.org/D73752. In our case it reproduces in Release (but not Debug) builds on Windows for x64 and the only test failing is CrashRecoveryTest.DumpStackCleanup. |
What compiler and version is the internal buildbot using, exactly? All released versions of clang-cl miscompile this testcase, so unless your bot builds clang and then rebuilds LLVM with the just-built clang and runs this test, you will still see the failure. |
We build the llvm-project with MSVC: -- The C compiler identification is MSVC 19.16.27035.0 And then I assume that the test cases get built with the just-built clang as that should be the default, right? |
I can repro that failure: The code crashes a second time here: 0:000> u eip 0:000> r rbp RBP should presumably not be null at this point. That seems like it could be a compiler bug, but maybe we did something odd to make that happen. |
That one landed, but since it's fixing an older problem and we have a good work-around on the branch, I'll pass on it for 10.x. Comment 14 makes it sound like there is another problem too though? |
Hans: There this also: https://reviews.llvm.org/D73809 |
Thanks! I see you put some comments on it, so I'll follow along and merge when it's all done. |
I think you can merge it as it is for 10.0, the patch fixes the bug. My comments are nice-to-haves to clean up the code, we can do that later. |
Okay, pushed to 10.x as dbe9c3a |
Extended Description
C:\src\llvm.monorepo\build.32_2019_selfhost>set CC=c:\src\llvm.monorepo\build.32_2019\bin\clang-cl.exe
C:\src\llvm.monorepo\build.32_2019_selfhost>set CXX=%CC%
C:\src\llvm.monorepo\build.32_2019_selfhost>cmake -GNinja -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_ENABLE_PROJECTS="llvm" ..\llvm
C:\src\llvm.monorepo\build.32_2019_selfhost>ninja SupportTests
C:\src\llvm.monorepo\build.32_2019_selfhost>unittests\Support\SupportTests.exe --gtest_filter=CrashRecovery*
Note: Google Test filter = CrashRecovery*
[==========] Running 5 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 5 tests from CrashRecoveryTest
[ RUN ] CrashRecoveryTest.Basic
unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ�.
[ FAILED ] CrashRecoveryTest.Basic (2 ms)
[ RUN ] CrashRecoveryTest.Cleanup
unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ�.
[ FAILED ] CrashRecoveryTest.Cleanup (0 ms)
[ RUN ] CrashRecoveryTest.DumpStackCleanup
0x011568E0 (0x01158560 0x011568E0 0x00000001 0x023CF598)
0x014B2ED2 (0x01561420 0x045B50A0 0x0453F620 0x01158514)
0x0157D1C1 (0x045B50A0 0x01562380 0x015F46E5 0x01562380)
0x015622F5 (0x5E30635E 0x00000000 0x0454D190 0x0453F620)
0x01563C35 (0x0156BD2C 0x005B1000 0x0454D190 0x00000000)
0x0156B405 (0x00E56001 0x00007FFF 0x015F4D63 0x023CF800)
0x0157D581 (0x0453F620 0x0156B170 0x015F4D7C 0x00000000)
unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ�.
[ FAILED ] CrashRecoveryTest.DumpStackCleanup (32 ms)
[ RUN ] CrashRecoveryTest.RaiseException
unknown file: error: SEH exception with code 0x3221225477 thrown in â─δë±Φ�.
[ FAILED ] CrashRecoveryTest.RaiseException (0 ms)
[ RUN ] CrashRecoveryTest.CallOutputDebugString
[ OK ] CrashRecoveryTest.CallOutputDebugString (0 ms)
[----------] 5 tests from CrashRecoveryTest (41 ms total)
[----------] Global test environment tear-down
[==========] 5 tests from 1 test case ran. (48 ms total)
[ PASSED ] 1 test.
[ FAILED ] 4 tests, listed below:
[ FAILED ] CrashRecoveryTest.Basic
[ FAILED ] CrashRecoveryTest.Cleanup
[ FAILED ] CrashRecoveryTest.DumpStackCleanup
[ FAILED ] CrashRecoveryTest.RaiseException
4 FAILED TESTS
I'm guessing this might be a problem with clang-cl's SEH support rather than with CrashRecovery, but maybe it was uncovered because of the new in-process-cc1 stuff.
The text was updated successfully, but these errors were encountered: