libclang uses a CrashRecoveryContext, and building a module does too. If a
module gets built through libclang, nested CrashRecoveryContexts are used. They
work fine with threads as things are stored in ThreadLocal variables, but in
LLVM_ENABLE_THREADS=OFF builds the two recovery contexts would write to the
same globals.
To fix, keep active CrashRecoveryContextImpls in a list and have the global
point to the innermost one, and do something similar for
tlIsRecoveringFromCrash.
Necessary (but not sufficient) for PR11974 and PR20325
http://reviews.llvm.org/D11770
llvm-svn: 244251
The patch is generated using this command:
tools/clang/tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
llvm/lib/
Thanks to Eugene Kosov for the original patch!
llvm-svn: 240137
set on the calling thread.
This allows libclang's indexing threads to propagate their priority to the clang module building threads.
rdar://17459872
llvm-svn: 211747
global ThreadLocals, thereby getting rid of the load-time initialization of those
objects and also getting rid of their destruction unless the LLVM client calls
llvm_shutdown.
llvm-svn: 190617
in the "parent" thread, when we are using CrashRecoveryContext::RunSafelyOnThread.
When using CrashRecoveryContext::RunSafelyOnThread, we would set a CrashRecoveryContextImpl* to a thread-local variable
for the "child" thread, but CrashRecoveryContext would erroneously clear it in the "parent" thread.
The result was that if CrashRecoveryContext::RunSafelyOnThread was called again in the "child" thread it would mess up
crash-recovery for its parent.
A test for this will be added in the clang repository.
rdar://14204560
llvm-svn: 184380
Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.
Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]
llvm-svn: 169131
- This works, but won't handle crashes on stack overflow, or signals delivered
to a thread other than the one that crashed. The latter is particular annoying
on Darwin, because SIGABRT tends to go to the main thread.
llvm-svn: 109717
- Designed as a simple wrapper to allow clients to attempt to catch crashes
(memory errors, assertion violations, etc.) and do some kind of recovery.
- Currently doesn't actually attempt to catch crashes.
llvm-svn: 109586
