summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/Unix/Signals.inc
Commit message (Collapse)AuthorAgeFilesLines
* [Support] Optionally call signal handlers when a function wrapped by the the ↵Alexandre Ganea2020-01-111-0/+16
| | | | | | | | | CrashRecoveryContext fails This patch allows for handling a failure inside a CrashRecoveryContext in the same way as the global exception/signal handler. A failure will have the same side-effect, such as cleanup of temporarty file, printing callstack, calling relevant signal handlers, and finally returning an exception code. This is an optional feature, disabled by default. This is a support patch for D69825. Differential Revision: https://reviews.llvm.org/D70568
* [Signal] Allow one-shot SIGPIPE handler to be reachedVedant Kumar2019-12-041-5/+5
| | | | | | | As SIGPIPE is no longer in the IntSigs array, handle SIGPIPE before handling any interrupt signals. Thanks to Alexandre Ganea for pointing out the issue here.
* [Signal] Allow llvm clients to opt into one-shot SIGPIPE handlingVedant Kumar2019-11-181-4/+20
| | | | | | | | | | | | | | | | | | | | Allow clients of the llvm library to opt-in to one-shot SIGPIPE handling, instead of forcing them to undo llvm's SIGPIPE handler registration (which is brittle). The current behavior is preserved for all llvm-derived tools (except lldb) by means of a default-`true` flag in the InitLLVM constructor. This prevents "IO error" crashes in long-lived processes (lldb is the motivating example) which both a) load llvm as a dynamic library and b) *really* need to ignore SIGPIPE. As llvm signal handlers can be installed when calling into libclang (say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the current model. Differential Revision: https://reviews.llvm.org/D70277
* Revert "Disable exit-on-SIGPIPE in lldb"Vedant Kumar2019-10-241-13/+1
| | | | | | | This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30. In post-commit review, Pavel pointed out that there's a simpler way to ignore SIGPIPE in lldb that doesn't rely on llvm's handlers.
* Disable exit-on-SIGPIPE in lldbVedant Kumar2019-10-181-1/+13
| | | | | | | | | | | | | | | | | | Occasionally, during test teardown, LLDB writes to a closed pipe. Sometimes the communication is inherently unreliable, so LLDB tries to avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`). However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to exit with IO_ERR. Opt LLDB out of the default SIGPIPE behavior. I expect that this will resolve some LLDB test suite flakiness (tests randomly failing with IO_ERR) that we've seen since r344372. rdar://55750240 Differential Revision: https://reviews.llvm.org/D69148 llvm-svn: 375288
* Replace llvm::MutexGuard/UniqueLock with their standard equivalentsBenjamin Kramer2019-08-071-1/+0
| | | | | | | All supported platforms have <mutex> now, so we don't need our own copies any longer. No functionality change intended. llvm-svn: 368149
* Support for dumping current PrettyStackTrace on SIGINFO (Ctrl-T)Jordan Rose2019-07-121-14/+53
| | | | | | | | | | | | | | | | | | | | Support SIGINFO (and SIGUSR1 for POSIX purposes) to tell what long-running jobs are doing, as inspired by BSD tools (including on macOS), by dumping the current PrettyStackTrace. This adds a new kind of signal handler for non-fatal "info" signals, similar to the "interrupt" handler that already exists for SIGINT (Ctrl-C). It then uses that handler to update a "generation count" managed by the PrettyStackTrace infrastructure, which is then checked whenever a PrettyStackTraceEntry is pushed or popped on each thread. If the generation has changed---i.e. if the user has pressed Ctrl-T---the stack trace is dumped, though unfortunately it can't include the deepest entry because that one is currently being constructed/destructed. https://reviews.llvm.org/D63750 llvm-svn: 365911
* [llvm] [Support] Clean PrintStackTrace() ptr arithmetic upMichal Gorny2019-07-021-5/+2
| | | | | | | | | | | | | | | | | Use '%tu' modifier for pointer arithmetic since we are using C++11 already. Prefer static_cast<> over C-style cast. Remove unnecessary conversion of result, and add const qualifier to converted pointers, to silence the following warning: In file included from /home/mgorny/llvm-project/llvm/lib/Support/Signals.cpp:220:0: /home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc: In function ‘void llvm::sys::PrintStackTrace(llvm::raw_ostream&)’: /home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc:546:53: warning: cast from type ‘const void*’ to type ‘char*’ casts away qualifiers [-Wcast-qual] (char*)dlinfo.dli_saddr)); ^~~~~~~~~ Differential Revision: https://reviews.llvm.org/D63888 llvm-svn: 364912
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Support] exit with custom return code for SIGPIPENick Desaulniers2018-10-121-0/+5
| | | | | | | | | | | | | | | | | | | | | Summary: We tell the user to file a bug report on LLVM right now, and SIGPIPE isn't LLVM's fault so our error message is wrong. Allows frontends to detect SIGPIPE from writing to closed readers. This can be seen commonly from piping into head, tee, or split. Fixes PR25349, rdar://problem/14285346, b/77310947 Reviewers: jfb Reviewed By: jfb Subscribers: majnemer, kristina, llvm-commits, thakis, srhines Differential Revision: https://reviews.llvm.org/D53000 llvm-svn: 344372
* Fix namespaces. No functionality change.Benjamin Kramer2018-06-161-0/+2
| | | | llvm-svn: 334890
* Signal handling should be signal-safeJF Bastien2018-05-161-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. Fix r332428 which I reverted in r332429. I originally used double-wide CAS because I was lazy, but some platforms use a runtime function for that which thankfully failed to link (it would have been bad for signal handlers otherwise). I use a separate flag to guard the data instead. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: steven_wu, llvm-commits llvm-svn: 332496
* Revert "Signal handling should be signal-safe"JF Bastien2018-05-161-161/+73
| | | | | | Some bots don't have double-pointer width compare-and-exchange. Revert for now.q llvm-svn: 332429
* Signal handling should be signal-safeJF Bastien2018-05-161-73/+161
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Before this patch, signal handling wasn't signal safe. This leads to real-world crashes. It used ManagedStatic inside of signals, this can allocate and can lead to unexpected state when a signal occurs during llvm_shutdown (because llvm_shutdown destroys the ManagedStatic). It also used cl::opt without custom backing storage. Some de-allocation was performed as well. Acquiring a lock in a signal handler is also a great way to deadlock. We can't just disable signals on llvm_shutdown because the signals might do useful work during that shutdown. We also can't just disable llvm_shutdown for programs (instead of library uses of clang) because we'd have to then mark the pointers as not leaked and make sure all the ManagedStatic uses are OK to leak and remain so. Move all of the code to lock-free datastructures instead, and avoid having any of them in an inconsistent state. I'm not trying to be fancy, I'm not using any explicit memory order because this code isn't hot. The only purpose of the atomics is to guarantee that a signal firing on the same or a different thread doesn't see an inconsistent state and crash. In some cases we might miss some state (for example, we might fail to delete a temporary file), but that's fine. Note that I haven't touched any of the backtrace support despite it not technically being totally signal-safe. When that code is called we know something bad is up and we don't expect to continue execution, so calling something that e.g. sets errno is the least of our problems. A similar patch should be applied to lib/Support/Windows/Signals.inc, but that can be done separately. <rdar://problem/28010281> Reviewers: dexonsmith Subscribers: aheejin, llvm-commits Differential Revision: https://reviews.llvm.org/D46858 llvm-svn: 332428
* [NFC] pull a function into its own lambdaJF Bastien2018-05-151-19/+21
| | | | | | | | | As requested in D46858, pulling this function into its own lambda makes it easier to read that part of the code and reason as to what's going on because the scope it can be called from is extremely limited. We want to keep it as a function because it's called from the two subsequent lines. llvm-svn: 332325
* [NFC] Update commentsJF Bastien2018-05-151-20/+19
| | | | | | Don't prepend function or data name before each comment. Split into its own NFC patch as requested in D46858. llvm-svn: 332323
* IWYU for llvm-config.h in llvm, additions.Nico Weber2018-04-301-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | See r331124 for how I made a list of files missing the include. I then ran this Python script: for f in open('filelist.txt'): f = f.strip() fl = open(f).readlines() found = False for i in xrange(len(fl)): p = '#include "llvm/' if not fl[i].startswith(p): continue if fl[i][len(p):] > 'Config': fl.insert(i, '#include "llvm/Config/llvm-config.h"\n') found = True break if not found: print 'not found', f else: open(f, 'w').write(''.join(fl)) and then looked through everything with `svn diff | diffstat -l | xargs -n 1000 gvim -p` and tried to fix include ordering and whatnot. No intended behavior change. llvm-svn: 331184
* Report fatal error in the case of out of memorySerge Pavlov2018-02-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is the second part of recommit of r325224. The previous part was committed in r325426, which deals with C++ memory allocation. Solution for C memory allocation involved functions `llvm::malloc` and similar. This was a fragile solution because it caused ambiguity errors in some cases. In this commit the new functions have names like `llvm::safe_malloc`. The relevant part of original comment is below, updated for new function names. Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. In some cases memory is allocated by a call to some of C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked for null pointer. To simplify checks, new functions are defined in the namespace 'llvm': `safe_malloc`, `safe_calloc` and `safe_realloc`. They behave as corresponding standard functions but produce fatal error if allocation fails. This change replaces the standard functions like 'malloc' in the cases when the result of the allocation function is not checked for null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statement is added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325551
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-151-1/+1
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Report fatal error in the case of out of memorySerge Pavlov2018-02-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Analysis of fails in the case of out of memory errors can be tricky on Windows. Such error emerges at the point where memory allocation function fails, but manifests itself when null pointer is used. These two points may be distant from each other. Besides, next runs may not exhibit allocation error. Usual programming practice does not require checking result of 'operator new' because it throws 'std::bad_alloc' in the case of allocation error. However, LLVM is usually built with exceptions turned off, so 'new' can return null pointer. This change installs custom new handler, which causes fatal error in the case of out of memory. The handler is installed automatically prior to call to 'main' during construction of a static object defined in 'lib/Support/ErrorHandling.cpp'. If the application does not use this file, the handler may be installed manually by a call to 'llvm::install_out_of_memory_new_handler', declared in 'include/llvm/Support/ErrorHandling.h". There are calls to C allocation functions, malloc, calloc and realloc. They are used for interoperability with C code, when allocated object has variable size and when it is necessary to avoid call of constructors. In many calls the result is not checked against null pointer. To simplify checks, new functions are defined in the namespace 'llvm' with the same names as these C function. These functions produce fatal error if allocation fails. User should use 'llvm::malloc' instead of 'std::malloc' in order to use the safe variant. This change replaces 'std::malloc' in the cases when the result of allocation function is not checked against null pointer. Finally, there are plain C code, that uses malloc and similar functions. If the result is not checked, assert statements are added. Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325224
* Sort the remaining #include lines in include/... and lib/....Chandler Carruth2017-06-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
* Fix detection of backtrace() availability on FreeBSDEd Maste2017-04-121-2/+2
| | | | | | | | | | | | On FreeBSD backtrace is not part of libc and depends on libexecinfo being available. Instead of using manual checks we can use the builtin CMake module FindBacktrace.cmake to detect availability of backtrace() in a portable way. Patch By: Alex Richardson Differential Revision: https://reviews.llvm.org/D27143 llvm-svn: 300062
* Remove name space pollution from Signals.cppKristof Beyls2017-03-311-3/+3
| | | | llvm-svn: 299224
* [Support] Avoid concurrency hazard in signal handler registrationBruno Cardoso Lopes2017-03-271-5/+1
| | | | | | | | | | | | | | | | | | Several static functions from the signal API can be invoked simultaneously; RemoveFileOnSignal for instance can be called indirectly by multiple parallel loadModule() invocations, which might lead to the assertion: Assertion failed: (NumRegisteredSignals < array_lengthof(RegisteredSignalInfo) && "Out of space for signal handlers!"), function RegisterHandler, file /llvm/lib/Support/Unix/Signals.inc, line 105. RemoveFileOnSignal calls RegisterHandlers(), which isn't currently mutex protected, leading to the behavior above. This potentially affect a few other users of RegisterHandlers() too. rdar://problem/30381224 llvm-svn: 298871
* Fix LLDB Android AArch64 GCC debug info buildOmair Javaid2017-02-021-1/+1
| | | | | | | | | Committing after fixing suggested changes and tested release/debug builds on x86_64-linux and arm/aarch64 builds. Differential revision: https://reviews.llvm.org/D29042 llvm-svn: 293850
* Revert "Use _Unwind_Backtrace on Apple platforms."Bob Wilson2017-01-061-1/+1
| | | | | | | | | | | This reverts commit 63165f6ae3bac1623be36d4b3ce63afa1d51a30a. After making this change, I discovered that _Unwind_Backtrace is unable to unwind past a signal handler after an assertion failure. I filed a bug report about that issue in rdar://29866587 but even if we get a fix soon, it will be awhile before it get released. llvm-svn: 291207
* Use _Unwind_Backtrace on Apple platforms.Bob Wilson2016-11-141-1/+1
| | | | | | | | | | | | | Darwin's backtrace() function does not work with sigaltstack (which was enabled when available with r270395) — it does a sanity check to make sure that the current frame pointer is within the expected stack area (which it is not when using an alternate stack) and gives up otherwise. The alternative of _Unwind_Backtrace seems to work fine on macOS, so use that when backtrace() fails. Note that we then use backtrace_symbols_fd() with the addresses from _Unwind_Backtrace, but I’ve tested that and it also seems to work fine. rdar://problem/28646552 llvm-svn: 286851
* fix build on cygwinNuno Lopes2016-10-061-1/+1
| | | | | | Cygwin has dlfcn.h, but no Dl_info llvm-svn: 283427
* Turn ENABLE_CRASH_OVERRIDES into a 0/1 definition.Joerg Sonnenberger2016-09-301-1/+1
| | | | llvm-svn: 282919
* Convert ENABLE_BACKTRACES into a 0/1 definition.Joerg Sonnenberger2016-09-301-4/+4
| | | | llvm-svn: 282918
* HAVE_UNWIND_BACKTRACE -> HAVE__UNWIND_BACKTRACEJoerg Sonnenberger2016-09-291-4/+4
| | | | | | Check for existance and not truth value. llvm-svn: 282767
* Add an c++ itanium demangler to llvm.Rafael Espindola2016-09-061-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a copy of the demangler in libcxxabi. The code also has no dependencies on anything else in LLVM. To enforce that I added it as another library. That way a BUILD_SHARED_LIBS will fail if anyone adds an use of StringRef for example. The no llvm dependency combined with the fact that this has to build on linux, OS X and Windows required a few changes to the code. In particular: No constexpr. No alignas On OS X at least this library has only one global symbol: __ZN4llvm16itanium_demangleEPKcPcPmPi My current plan is: Commit something like this Change lld to use it Change lldb to use it as the fallback Add a few #ifdefs so that exactly the same file can be used in libcxxabi to export abi::__cxa_demangle. Once the fast demangler in lldb can handle any names this implementation can be replaced with it and we will have the one true demangler. llvm-svn: 280732
* Preserve a pointer to the newly allocated signal stack as well. That tooChandler Carruth2016-08-241-4/+6
| | | | | | is flagged by LSan at least among leak detectors. llvm-svn: 279605
* Increase the size of the sigaltstack used by LLVM signal handlers. 8KB is notRichard Smith2016-08-241-1/+1
| | | | | | | | sufficient in some cases; increase to 64KB, which should be enough for anyone :) Patch by github.com/bryant! llvm-svn: 279599
* Use the range variant of find/find_if instead of unpacking begin/endDavid Majnemer2016-08-121-1/+1
| | | | | | | | | If the result of the find is only used to compare against end(), just use is_contained instead. No functionality change is intended. llvm-svn: 278469
* Search for llvm-symbolizer binary in the same directory as argv[0], beforeRichard Smith2016-06-091-2/+7
| | | | | | | looking for it along $PATH. This allows installs of LLVM tools outside of $PATH to find the symbolizer and produce pretty backtraces if they crash. llvm-svn: 272232
* [Support] Reapply cleanup r270643Gerolf Hoflehner2016-05-251-39/+0
| | | | llvm-svn: 270674
* [Support] revert previous commit r270643Gerolf Hoflehner2016-05-251-0/+39
| | | | llvm-svn: 270670
* [Support] Cleanup of an ancient Darwin work-around in Signals.inc (PR26174)Gerolf Hoflehner2016-05-251-39/+0
| | | | | | Patch by Jeremy Huddleston Sequoia llvm-svn: 270643
* Enable use of sigaltstack for signal handlers when available. With this,Richard Smith2016-05-231-1/+1
| | | | | | | backtraces from the signal handler on stack overflow now work reliably (on my system at least...). llvm-svn: 270395
* Fix implicit type conversion. NFC.Chris Bieneman2016-05-211-1/+1
| | | | llvm-svn: 270299
* Switch from the linux-specific 'struct sigaltstack' to POSIX's 'stack_t'. ThisRichard Smith2016-05-201-2/+2
| | | | | | is what I get for trusting my system's man pages I suppose. llvm-svn: 270280
* Add a configure-time check for the existence of sigaltstack. It seems that someRichard Smith2016-05-201-2/+4
| | | | | | systems provide a <signal.h> that doesn't declare it. llvm-svn: 270278
* Reinstate r269992 (reverting r270267), but restricted to cases where glibc isRichard Smith2016-05-201-4/+59
| | | | | | | | | the C standard library implementation in use. This works around a glibc bug in the backtrace() function where it fails to produce a backtrace on x86_64 if libgcc / libunwind is statically linked. llvm-svn: 270276
* Create a sigaltstack when we register our signal handlers. Otherwise we'd veryRichard Smith2016-05-201-0/+31
| | | | | | likely fail to produce a backtrace if we crash due to stack overflow. llvm-svn: 270273
* Revert "Work around a glibc bug: backtrace() spuriously fails if..."Chris Bieneman2016-05-201-51/+4
| | | | | | | | | This commit has been breaking the FreeBSD bots: http://lab.llvm.org:8011/builders/lld-x86_64-freebsd This reverts commit r269992. llvm-svn: 270267
* Work around a glibc bug: backtrace() spuriously fails ifRichard Smith2016-05-181-4/+51
| | | | | | | | | | | | - glibc is dynamically linked, and - libgcc_s is unavailable (for instance, another library is being used to provide the compiler runtime or libgcc is statically linked), and - the target is x86_64. If we run backtrace() and it fails to find any stack frames, try using _Unwind_Backtrace instead if available. llvm-svn: 269992
* Revert "Fix Clang-tidy modernize-deprecated-headers warnings in remaining ↵Duncan P. N. Exon Smith2016-04-051-29/+24
| | | | | | | | | | files; other minor fixes." This reverts commit r265454 since it broke the build. E.g.: http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/22413/ llvm-svn: 265459
* Fix Clang-tidy modernize-deprecated-headers warnings in remaining files; ↵Eugene Zelenko2016-04-051-24/+29
| | | | | | | | | | | | other minor fixes. Some Include What You Use suggestions were used too. Use anonymous namespaces in source files. Differential revision: http://reviews.llvm.org/D18778 llvm-svn: 265454
* Use array_lengthof instead of manually calculating it. NFCCraig Topper2015-12-011-3/+2
| | | | llvm-svn: 254380
OpenPOWER on IntegriCloud