summaryrefslogtreecommitdiffstats
path: root/llvm/lib/Support/ErrorHandling.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [Clang][Driver] After default -fintegrated-cc1, make ↵Alexandre Ganea2020-02-121-1/+2
| | | | | | | | | | | | | llvm::report_fatal_error() generate preprocessed source + reproducer.sh again. Added a test for #pragma clang __debug llvm_fatal_error to test for the original issue. Added llvm::sys::Process::Exit() and replaced ::exit() in places where it was appropriate. This new function would call the current CrashRecoveryContext if one is running on the same thread; or call ::exit() otherwise. Fixes PR44705. Differential Revision: https://reviews.llvm.org/D73742 (cherry picked from commit faace365088a2a3a4cb1050a9facfc34a7a56577)
* [Support] Move the static initializer install_out_memory_new_handler to InitLLVMFangrui Song2019-07-121-17/+5
| | | | | | | | | | | An application linking against LLVMSupport should not get the gratuitous set::std_new_handler call. Reviewed By: jfb Differential Revision: https://reviews.llvm.org/D64505 llvm-svn: 365915
* 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
* s/LLVM_ON_WIN32/_WIN32/, llvmNico Weber2018-04-291-1/+1
| | | | | | | | | | | | | | LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the default macro instead of a reinvented one. See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev. No intended behavior change. This moves over all uses of the macro, but doesn't remove the definition of it in (llvm-)config.h yet. llvm-svn: 331127
* Report fatal error in the case of out of memorySerge Pavlov2018-02-171-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | This is partial recommit of r325224, reverted in 325227. The relevant part of original comment is below. 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". Differential Revision: https://reviews.llvm.org/D43010 llvm-svn: 325426
* Revert r325224 "Report fatal error in the case of out of memory"Serge Pavlov2018-02-151-33/+0
| | | | | | It caused fails on some buildbots. llvm-svn: 325227
* Report fatal error in the case of out of memorySerge Pavlov2018-02-151-0/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Defeat a GCC -Wunused-result warningHans Wennborg2017-07-191-1/+2
| | | | | | | | | | | | | | | It was warning like: ../llvm-project/llvm/lib/Support/ErrorHandling.cpp:172:51: warning: ignoring return value of ‘ssize_t write(int, const void*, size_t)’, declared with attribute warn_unused_result [-Wunused-result] (void)::write(2, OOMMessage, strlen(OOMMessage)); Work around the warning by storing the return value in a variable and casting that to void instead. We already did this for the other write() call in this file. llvm-svn: 308483
* Put std::mutex usage behind #ifdefs to pacify the sanitizer buildbotReid Kleckner2017-07-131-0/+22
| | | | llvm-svn: 307925
* Use std::mutex to avoid memory allocation after OOMReid Kleckner2017-07-121-13/+18
| | | | | | | | | | | | | | | ManagedStatic<sys::Mutex> would lazilly allocate a sys::Mutex to lock when reporting an OOM, which is a bad idea. The three STL implementations that I know of use pthread_mutex_lock and EnterCriticalSection to implement std::mutex. I'm pretty sure that neither of those allocate heap memory. It seems that we unconditionally use std::mutex without testing LLVM_ENABLE_THREADS elsewhere in the codebase, so this should be portable. llvm-svn: 307827
* [Support] - Add bad alloc error handler for handling allocation malfunctionsReid Kleckner2017-07-111-1/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Patch by Klaus Kretzschmar We would like to introduce a new type of llvm error handler for handling bad alloc fault situations. LLVM already provides a fatal error handler for serious non-recoverable error situations which by default writes some error information to stderr and calls exit(1) at the end (functions are marked as 'noreturn'). For long running processes (e.g. a server application), exiting the process is not an acceptable option, especially not when the system is in a temporary resource bottleneck with a good chance to recover from this fault situation. In such a situation you would rather throw an exception to stop the current compilation and try to overcome the resource bottleneck. The user should be aware of the problem of throwing an exception in bad alloc situations, e.g. you must not do any allocations in the unwind chain. This is especially true when adding exceptions in existing unfamiliar code (as already stated in the comment of the current fatal error handler) So the new handler can also be used to distinguish from general fatal error situations where recovering is no option. It should be used in cases where a clean unwind after the allocation is guaranteed. This patch contains: - A report_bad_alloc function which calls a user defined bad alloc error handler. If no user handler is registered the report_fatal_error function is called. This function is not marked as 'noreturn'. - A install/restore_bad_alloc_error_handler to install/restore the bad alloc handler. - An example (in Mutex.cpp) where the report_bad_alloc function is called in case of a malloc returns a nullptr. If this patch gets accepted we would create similar patches to fix corresponding malloc/calloc usages in the llvm code. Reviewers: chandlerc, greened, baldrick, rnk Reviewed By: rnk Subscribers: llvm-commits, MatzeB Differential Revision: https://reviews.llvm.org/D34753 llvm-svn: 307673
* [Support] Make all Errors convertible to std::error_code.Lang Hames2016-03-231-3/+0
| | | | | | | | | | | | This is a temporary crutch to enable code that currently uses std::error_code to be incrementally moved over to Error. Requiring all Error instances be convertible enables clients to call errorToErrorCode on any error (not just ECErrors created by conversion *from* an error_code). This patch also moves code for Error from ErrorHandling.cpp into a new Error.cpp file. llvm-svn: 264221
* [Support] Add the 'Error' class for structured error handling.Lang Hames2016-03-161-0/+4
| | | | | | | | | | | | | | | | | This patch introduces the Error classs for lightweight, structured, recoverable error handling. It includes utilities for creating, manipulating and handling errors. The scheme is similar to exceptions, in that errors are described with user-defined types. Unlike exceptions however, errors are represented as ordinary return types in the API (similar to the way std::error_code is used). For usage notes see the LLVM programmer's manual, and the Error.h header. Usage examples can be found in unittests/Support/ErrorTest.cpp. Many thanks to David Blaikie, Mehdi Amini, Kevin Enderby and others on the llvm-dev and llvm-commits lists for lots of discussion and review. llvm-svn: 263609
* Reorganize the C API headers to improve build times.Eric Christopher2015-12-181-1/+1
| | | | | | | | | Type specific declarations have been moved to Type.h and error handling routines have been moved to ErrorHandling.h. Both are included in Core.h so nothing should change for projects directly including the headers, but transitive dependencies may be affected. llvm-svn: 255965
* [cleanup] Re-sort all the #include lines in LLVM usingChandler Carruth2015-01-141-1/+1
| | | | | | | | | | | utils/sort_includes.py. I clearly haven't done this in a while, so more changed than usual. This even uncovered a missing include from the InstrProf library that I've added. No functionality changed here, just mechanical cleanup of the include order. llvm-svn: 225974
* Converting the ErrorHandlerMutex to a ManagedStatic to avoid the static ↵Chris Bieneman2014-10-031-4/+5
| | | | | | constructor and destructor. llvm-svn: 219028
* Merge lib/Support/WindowsError.cpp into ib/Support/ErrorHandling.cpp.Rafael Espindola2014-06-171-0/+69
| | | | | | | The OSX ranlib warns on files with no symbols, and lib/Support/WindowsError.cpp was empty when building on non-windows. llvm-svn: 211118
* Make the error-handling functions thread-safe.Zachary Turner2014-06-131-4/+19
| | | | | | | | | | | | | Prior to this change, error handling functions must be installed and removed only inside of an llvm_[start/stop]_multithreading pair. This change allows error handling functions to be installed any time, and from any thread. Reviewed by: chandlerc Differential Revision: http://reviews.llvm.org/D4140 llvm-svn: 210937
* Revert "Remove support for runtime multi-threading."Zachary Turner2014-06-101-6/+2
| | | | | | This reverts revision r210600. llvm-svn: 210603
* Remove support for runtime multi-threading.Zachary Turner2014-06-101-2/+6
| | | | | | | | | | | | | | | | | | | | | This patch removes the functions llvm_start_multithreaded() and llvm_stop_multithreaded(), and changes llvm_is_multithreaded() to return a constant value based on the value of the compile-time definition LLVM_ENABLE_THREADS. Previously, it was possible to have compile-time support for threads on, and runtime support for threads off, in which case certain mutexes were not allocated or ever acquired. Now, if the build is created with threads enabled, mutexes are always acquired. A test before/after patch of compiling a very large TU showed no noticeable performance impact of this change. Reviewers: rnk Differential Revision: http://reviews.llvm.org/D4076 llvm-svn: 210600
* [C++11] Make use of 'nullptr' in the Support library.Craig Topper2014-04-071-3/+3
| | | | llvm-svn: 205697
* Roll back the ConstStringRef change for nowAlp Toker2014-01-271-1/+1
| | | | | | | | | | | There are a couple of interesting things here that we want to check over (particularly the expecting asserts in StringRef) and get right for general use in ADT so hold back on this one. For clang we have a workable templated solution to use in the meanwhile. This reverts commit r200187. llvm-svn: 200194
* StringRef: Extend constexpr capabilities and introduce ConstStringRefAlp Toker2014-01-271-1/+1
| | | | | | | | | | | | | | | | | | | (1) Add llvm_expect(), an asserting macro that can be evaluated as a constexpr expression as well as a runtime assert or compiler hint in release builds. This technique can be used to construct functions that are both unevaluated and compiled depending on usage. (2) Update StringRef using llvm_expect() to preserve runtime assertions while extending the same checks to static asserts in C++11 builds that support the feature. (3) Introduce ConstStringRef, a strong subclass of StringRef that references compile-time constant strings. It's convertible to, but not from, ordinary StringRef and thus can be used to add compile-time safety to various interfaces in LLVM and clang that only accept fixed inputs such as diagnostic format strings that tend to get misused. llvm-svn: 200187
* Re-sort all of the includes with ./utils/sort_includes.py so thatChandler Carruth2014-01-071-1/+1
| | | | | | | | | | subsequent changes are easier to review. About to fix some layering issues, and wanted to separate out the necessary churn. Also comment and sink the include of "Windows.h" in three .inc files to match the usage in Memory.inc. llvm-svn: 198685
* Revert r194865 and r194874.Alexey Samsonov2013-11-181-2/+0
| | | | | | | | | | | | This change is incorrect. If you delete virtual destructor of both a base class and a subclass, then the following code: Base *foo = new Child(); delete foo; will not cause the destructor for members of Child class. As a result, I observe plently of memory leaks. Notable examples I investigated are: ObjectBuffer and ObjectBufferStream, AttributeImpl and StringSAttributeImpl. llvm-svn: 194997
* [weak vtables] Remove a bunch of weak vtablesJuergen Ributzka2013-11-151-0/+2
| | | | | | | | | | | This patch removes most of the trivial cases of weak vtables by pinning them to a single object file. Differential Revision: http://llvm-reviews.chandlerc.com/D2068 Reviewed by Andy llvm-svn: 194865
* Fix the -Werror -Wpedantic clang selfhost buildAlp Toker2013-10-221-3/+3
| | | | | | | | This is a stopgap fix for cast warnings introduced in r192864. A proper fix should be investigated by the author when possible. llvm-svn: 193160
* Expose install_fatal_error_handler() through the C API.Filip Pizlo2013-10-171-0/+17
| | | | | | | | | | | | | | | | | I expose the API with some caveats: - The C++ API involves a traditional void* opaque pointer for the fatal error callback. The C API doesn’t do this. I don’t think that the void* opaque pointer makes any sense since this is a global callback - there will only be one of them. So if you need to pass some data to your callback, just put it in a global variable. - The bindings will ignore the gen_crash_diag boolean. I ignore it because (1) I don’t know what it does, (2) it’s not documented AFAIK, and (3) I couldn’t imagine any use for it. I made the gut call that it probably wasn’t important enough to expose through the C API. llvm-svn: 192864
* [Support] Fix some warnings when self-hosting clang on WindowsReid Kleckner2013-07-161-0/+5
| | | | llvm-svn: 186413
* Add a boolean parameter to the llvm::report_fatal_error() function to indicatedChad Rosier2013-03-271-8/+8
| | | | | | | if crash diagnostics should be generated. By default this is enabled. Part of rdar://13296693 llvm-svn: 178161
* Use the new script to sort the includes of every file under lib.Chandler Carruth2012-12-031-4/+4
| | | | | | | | | | | | | | | | | 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
* Revert 167755/167760. We don't want to emit crash diagnostics on ↵Chad Rosier2012-11-131-4/+1
| | | | | | command-line syntax errors. llvm-svn: 167849
* Revert r167620; this can be implemented using an existing CL option.Chad Rosier2012-11-121-1/+4
| | | | llvm-svn: 167755
* Like the coding standards say, do not use "using namespace std".Jay Foad2011-04-231-1/+0
| | | | llvm-svn: 130054
* Merge System into Support.Michael J. Spencer2010-11-291-2/+2
| | | | llvm-svn: 120298
* report_fatal_error: Simplify a possible ambiguity.Daniel Dunbar2010-11-131-0/+4
| | | | llvm-svn: 118972
* Some versions of gcc still warn about "ignoring return value ... declaredDuncan Sands2010-09-161-1/+2
| | | | | | with attribute warn_unused_result" here - suppress the warning harder. llvm-svn: 114072
* Tidy.Dan Gohman2010-08-181-5/+4
| | | | llvm-svn: 111432
* include config.h to get config params, hopefully unbreaking mingw builder.Chris Lattner2010-08-171-0/+1
| | | | llvm-svn: 111325
* report_fatal_error can't use errs(), because errs() can call Chris Lattner2010-08-171-8/+26
| | | | | | | into report_fatal_error. Just blast the string to stderr with write(2) and hope for the best! Part of rdar://8318441 llvm-svn: 111320
* Run interrupt routines as part of report_fatal_error, since we are failingDaniel Dunbar2010-05-081-0/+7
| | | | | | ungracefully. llvm-svn: 103334
* rename llvm_install_error_handler -> install_fatal_error_handlerChris Lattner2010-04-071-16/+13
| | | | | | and friends. llvm-svn: 100717
* rename llvm::llvm_report_error -> llvm::report_fatal_errorChris Lattner2010-04-071-5/+5
| | | | llvm-svn: 100709
* Fix minor style issues.Dan Gohman2010-03-241-3/+2
| | | | llvm-svn: 99414
* Change errs() to dbgs().David Greene2010-01-051-4/+5
| | | | llvm-svn: 92637
* Add a comment explaining why llvm_unreachable_internal doesn't callDan Gohman2009-08-201-0/+3
| | | | | | the ErrorHandler callback. llvm-svn: 79541
* This void is implicit in C++.Dan Gohman2009-08-121-1/+1
| | | | llvm-svn: 78848
* Add support for a user supplied pointer argument to llvm_install_error_handler.Daniel Dunbar2009-08-101-2/+6
| | | | llvm-svn: 78553
* Allow llvm_report_error to accept a Twine.Daniel Dunbar2009-07-241-3/+12
| | | | llvm-svn: 76961
* llvm_unreachable->llvm_unreachable(0), LLVM_UNREACHABLE->llvm_unreachable.Torok Edwin2009-07-141-1/+1
| | | | | | | | | This adds location info for all llvm_unreachable calls (which is a macro now) in !NDEBUG builds. In NDEBUG builds location info and the message is off (it only prints "UREACHABLE executed"). llvm-svn: 75640
OpenPOWER on IntegriCloud