V8 CL crashes Clang on Win64 |
|||||||||
Issue descriptionI have a V8 Cl that reproducibly crashes clang on Win64. https://codereview.chromium.org/2630553002/#ps100001 Build log here: https://uberchromegw.corp.google.com/i/client.v8/builders/V8%20Win64%20-%20clang/builds/4471/steps/compile/logs/stdio Snippet of log that contains the failure. [752/802] CXX obj/test/unittests/unittests/function-body-decoder-unittest.obj FAILED: obj/test/unittests/unittests/function-body-decoder-unittest.obj E:\b\build\slave\cache\cipd\goma/gomacc.exe ../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo /showIncludes /FC @obj/test/unittests/unittests/function-body-decoder-unittest.obj.rsp /c ../../test/unittests/wasm/function-body-decoder-unittest.cc /Foobj/test/unittests/unittests/function-body-decoder-unittest.obj /Fd"obj/test/unittests/unittests_cc.pdb" Assertion failed: (NumGaps == 0 || Bias < MaxDefRange) && "large ranges should not have gaps", file E:\b\build\slave\win_upload_clang\build\src\third_party\llvm\lib\MC\MCCodeView.cpp, line 531 Wrote crash dump file "C:\Users\CHROME~2\AppData\Local\Temp\goma_temp.4512\clang-cl.exe-b70b88.dmp" #0 0x0000000140ad6aa6 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1506aa6) #1 0x00000001427148db (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x31448db) #2 0x000000014270ebf4 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x313ebf4) #3 0x000000014270125e (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x313125e) #4 0x00000001427012fa (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x31312fa) #5 0x0000000140942759 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1372759) #6 0x0000000140930728 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1360728) #7 0x000000014092f521 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x135f521) #8 0x000000014092fa2a (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x135fa2a) #9 0x0000000140923fdc (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1353fdc) #10 0x0000000141165f1b (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1b95f1b) #11 0x00000001406e1118 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1111118) #12 0x00000001406e177f (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x111177f) #13 0x0000000140d33c0b (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1763c0b) #14 0x00000001426c5192 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x30f5192) #15 0x000000014110961c (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1b3961c) #16 0x00000001417dd4b2 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x220d4b2) #17 0x00000001410cf84c (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1aff84c) #18 0x00000001410c1181 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1af1181) #19 0x0000000141141fe6 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x1b71fe6) #20 0x000000013f5d5f65 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x5f65) #21 0x000000013f5d42a2 (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x42a2) #22 0x00000001426fa9bd (E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin\clang-cl.exe+0x312a9bd) #23 0x0000000077a159bd (C:\Windows\system32\kernel32.dll+0x159bd) #24 0x0000000077c4a2e1 (C:\Windows\SYSTEM32\ntdll.dll+0x2a2e1) clang-cl.exe: error: clang frontend command failed due to signal (use -v to see invocation) clang version 4.0.0 (trunk 289944) Target: x86_64-pc-windows-msvc Thread model: posix InstalledDir: E:\b\build\slave\win64-clang\build\v8\third_party\llvm-build\Release+Asserts\bin clang-cl.exe: note: diagnostic msg: PLEASE submit a bug report to http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and associated run script. clang-cl.exe: note: diagnostic msg: ******************** PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: clang-cl.exe: note: diagnostic msg: C:\Users\CHROME~2\AppData\Local\Temp\goma_temp.4512\function-body-decoder-unittest-273138.sh clang-cl.exe: note: diagnostic msg: ******************** [753/802] CXX obj/test/unittests/unittests/bytecode-register-allocator-unittest.obj [754/802] CXX obj/test/unittests/unittests/constant-array-builder-unittest.obj [755/802] CXX obj/test/unittests/unittests/loop-assignment-analysis-unittest.obj [756/802] LINK v8_simple_wasm_data_section_fuzzer.exe v8_simple_wasm_data_section_fuzzer.exe.pdb [757/802] LINK v8_simple_wasm_function_sigs_section_fuzzer.exe v8_simple_wasm_function_sigs_section_fuzzer.exe.pdb [758/802] LINK v8_simple_wasm_fuzzer.exe v8_simple_wasm_fuzzer.exe.pdb [759/802] CXX obj/test/unittests/unittests/value-serializer-unittest.obj [760/802] CXX obj/test/unittests/unittests/bytecode-decoder-unittest.obj ninja: build stopped: subcommand failed. step returned non-zero exit code: 1 @@@STEP_FAILURE@@@
,
Jan 13 2017
Thanks for the report, I can repro. (symbol_level=0 hides the bug; only happens in release builds.) These args.gn repro: is_debug = false is_clang = true reducing...
,
Jan 13 2017
Some notes:
- I had to remove __movsb, __movsd, __movsw, __movsq, __stosd, __stosw, __stosq to build the repro file on my linux box, else the compile would fail with things like:
C:\src\chrome\src\third_party\llvm-build\Release+Asserts\bin\..\lib\clang\4.0.0\include\intrin.h(1014,27): error: asm-specifier for input or output variable conflicts with asm clobber list
: "%edi", "%esi", "%ecx");
^
That's surprising to me.
- For reasons I don't understand, the preprocessed file seems to end up with to copies of intrin.h -- but maybe that's just the way -frewrite-includes (what creates the crash files) works
- The file builds for 21s before it crashes on my linux box. delta will take forever in this setup.
,
Jan 13 2017
- does not repro in 32-bit builds
,
Jan 13 2017
It looks like this happens because something believes that FunctionBodyDecoderTest has too many tests. (It has 202.) If I comment out an arbitrary test, things compile fine. This is of course a compiler bug, but as a workaround you could a) fuse some of the If_ tests into a single If test b) consider splitting that fiel up a bit, it's 2.7k lines and takes like 20 seconds to build -- so that's probably a good idea anyhow. We'll get the compiler crash fixed, and hopefully it won't take long, but if you don't want to wait for that those are ideas for you not being blocked on us.
,
Jan 15 2017
Thanks for investigating. I'll follow your suggestion and collapse a couple of tests together. It's rather amazing that that file takes so long to compile, as it doesn't seem to do anything too crazy, except have a lot of tests for one class. I guess it's gmock then.
,
Jan 15 2017
Ima Go out on a limb and claim that gmock will compile even slower.
,
Jan 15 2017
Sorry, I meant gtest. I don't want to switch to gmock :O
,
Jan 23 2017
Filed https://llvm.org/bugs/show_bug.cgi?id=31726
,
Jan 25 2017
,
Mar 1 2017
titzer: This is now fixed in chromium's clang. You can try to remove workarounds you put in for this. After that, this can be closed.
,
Mar 7 2017
titzer: ping. I'd like to close this.
,
Mar 7 2017
Closing with WontFix, as the external dependency is now resolved. Thanks! |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by titzer@chromium.org
, Jan 13 2017