Index/crash-recovery-modules.m fails for me, probably because of --disable-threads

[nico]

Bugzilla Link	11974
Resolution	FIXED
Resolved on	Aug 07, 2015 12:49
Version	unspecified
OS	All
CC	@akyrtzi,@DougGregor,@tschwinge

[nico]

FAIL: Clang :: Index/crash-recovery-modules.m (2245 of 10012)
******************** TEST 'Clang :: Index/crash-recovery-modules.m' FAILED ********************
Script:

rm -rf /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/tools/clang/test/Index/Output/crash-recovery-modules.m.tmp
not env CINDEXTEST_FAILONERROR=1 c-index-test -test-load-source all -fmodules -fmodule-cache-path /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/tools/clang/test/Index/Output/crash-recovery-modules.m.tmp -Xclang -fdisable-module-hash -I /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/test/Index/Inputs/Headers -DCRASH /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/test/Index/crash-recovery-modules.m 2> /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/tools/clang/test/Index/Output/crash-recovery-modules.m.tmp.err
FileCheck < /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/tools/clang/test/Index/Output/crash-recovery-modules.m.tmp.err -check-prefix=CHECK-CRASH /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/test/Index/crash-recovery-modules.m
env CINDEXTEST_FAILONERROR=1 c-index-test -test-load-source all -fmodules -fmodule-cache-path /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/tools/clang/test/Index/Output/crash-recovery-modules.m.tmp -Xclang -fdisable-module-hash -I /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/test/Index/Inputs/Headers /Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/test/Index/crash-recovery-modules.m

Exit Code: 1

---

Testing Time: 82.67s

---

Failing Tests (1):
Clang :: Index/crash-recovery-modules.m

[d0k]

*** Bug llvm/llvm-bugzilla-archive#12095 has been marked as a duplicate of this bug. ***

[llvmbot]

Yup, I built with --disable-threads.

[d0k]

*** Bug llvm/llvm-bugzilla-archive#15193 has been marked as a duplicate of this bug. ***

[llvmbot]

*** Bug llvm/llvm-bugzilla-archive#23400 has been marked as a duplicate of this bug. ***

[llvmbot]

The assertion is correct and result of duplicate construction vs. one destruction of

PrettyStackTraceParserEntry CrashInfo(P);

in clang::ParseAST. This maybe happen due to the LLVM_BUILTIN_TRAP (__builtin_trap) call of #pragma __debug crash. It seems to somehow call ParseAST again without calling the destructor.

I also suspected CrashRecoveryContextCleanupRegistrar with its setjmp longjmp but commenting it out did not pass the test.

[nico]

In a cmake build, it's spelled -DLLVM_ENABLE_THREADS=OFF instead of --disable-threads (further keywords -DLLVM_ENABLE_THREADS DLLVM_ENABLE_THREADS)

[nico]

I guess the problem is that CrashRecoveryContexts don't nest in thread-disabled builds. libclang wraps everything it does in CrashRecoveryContexts, while Frontend only uses one for module builds. So this test is the only case where they nest. If I do

• llvm::CrashRecoveryContext CRC;
• CRC.RunSafelyOnThread(& { Instance.ExecuteAction(CreateModuleAction); },

•                    ThreadStackSize);
  

• Instance.ExecuteAction(CreateModuleAction);

then this test passes (but in return module builds won't get crash recovery).

[nico]

Oh hm, the PrettyStack stuff is probably because it keeps the head of the pretty stack list in a thread-local variable, and in the module case we skip the destructors of all pretty stack thingies on the stack for building the module when the module build crashes.

[nico]

llvm part
(description coming up with 2nd attachment)

[nico]

clang part
Ok, I think this basically boils down to CrashRecoveryContext.cpp keeping cleanups in a ManagedStatic. If there's more than one CrashRecoveryContext, the cleanups of the two contexts get mixed up. Fixing that then shows that PrettyStackTrace also has a thread-local that has a similar problem. The attached proof-of-concept manually adds a CrashRecoveryCleanup that stores the pretty stack top before going down a parse and restores it if things crash, so if a module build crashes the pretty stack from the surrounding frontend CompilerInstance remains unharmed.

The test still fails with this, but much later. (I'll poke at it more.)

[nico]

llvm part
With this, this test and LibclangReparseTest.ReparseWithModule both pass (and all other tests seem to pass too – might need some tweaking to keep them passing with threads enabled).

[nico]

(fixes issue 20325 too)

[nico]

Part 1: http://reviews.llvm.org/D11770

[nico]

*** Bug llvm/llvm-bugzilla-archive#20325 has been marked as a duplicate of this bug. ***