Report fatal error in the case of out of memory

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

Report fatal error in the case of out of memory

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

show more ...

Defeat a GCC -Wunused-result warning

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)’,

Defeat a GCC -Wunused-result warning

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

show more ...

Put std::mutex usage behind #ifdefs to pacify the sanitizer buildbot

llvm-svn: 307925

Use std::mutex to avoid memory allocation after OOM

ManagedStatic<sys::Mutex> would lazilly allocate a sys::Mutex to lock
when reporting an OOM, which is a bad idea.

The three STL implementations t

Use std::mutex to avoid memory allocation after OOM

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

show more ...

[Support] - Add bad alloc error handler for handling allocation malfunctions

Summary:
Patch by Klaus Kretzschmar

We would like to introduce a new type of llvm error handler for handling
bad alloc f

[Support] - Add bad alloc error handler for handling allocation malfunctions

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

show more ...

[Support] Make all Errors convertible to std::error_code.

This is a temporary crutch to enable code that currently uses std::error_code
to be incrementally moved over to Error. Requiring all Error i

[Support] Make all Errors convertible to std::error_code.

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

show more ...

[Support] Add the 'Error' class for structured error handling.

This patch introduces the Error classs for lightweight, structured,
recoverable error handling. It includes utilities for creating, man

[Support] Add the 'Error' class for structured error handling.

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

show more ...

Reorganize the C API headers to improve build times.

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

Reorganize the C API headers to improve build times.

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

show more ...

[cleanup] Re-sort all the #include lines in LLVM using
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 Inst

[cleanup] Re-sort all the #include lines in LLVM using
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

show more ...

Converting the ErrorHandlerMutex to a ManagedStatic to avoid the static constructor and destructor.

llvm-svn: 219028

Merge lib/Support/WindowsError.cpp into ib/Support/ErrorHandling.cpp.

The OSX ranlib warns on files with no symbols, and lib/Support/WindowsError.cpp
was empty when building on non-windows.

llvm-sv

Merge lib/Support/WindowsError.cpp into ib/Support/ErrorHandling.cpp.

The OSX ranlib warns on files with no symbols, and lib/Support/WindowsError.cpp
was empty when building on non-windows.

llvm-svn: 211118

show more ...

Make the error-handling functions thread-safe.

Prior to this change, error handling functions must be installed
and removed only inside of an llvm_[start/stop]_multithreading
pair. This change allo

Make the error-handling functions thread-safe.

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

show more ...

Revert "Remove support for runtime multi-threading."

This reverts revision r210600.

llvm-svn: 210603

Remove support for runtime multi-threading.

This patch removes the functions llvm_start_multithreaded() and
llvm_stop_multithreaded(), and changes llvm_is_multithreaded()
to return a constant value

Remove support for runtime multi-threading.

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

show more ...

[C++11] Make use of 'nullptr' in the Support library.

llvm-svn: 205697

Roll back the ConstStringRef change for now

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
i

Roll back the ConstStringRef change for now

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

show more ...

StringRef: Extend constexpr capabilities and introduce ConstStringRef

(1) Add llvm_expect(), an asserting macro that can be evaluated as a constexpr
expression as well as a runtime assert or com

StringRef: Extend constexpr capabilities and introduce ConstStringRef

(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

show more ...

Re-sort all of the includes with ./utils/sort_includes.py so that
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.

Also com

Re-sort all of the includes with ./utils/sort_includes.py so that
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

show more ...

Revert r194865 and r194874.

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

Revert r194865 and r194874.

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

show more ...

[weak vtables] Remove a bunch of weak vtables

This patch removes most of the trivial cases of weak vtables by pinning them to
a single object file.

Differential Revision: http://llvm-reviews.chandl

[weak vtables] Remove a bunch of weak vtables

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

show more ...

Fix the -Werror -Wpedantic clang selfhost build

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.

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

Expose install_fatal_error_handler() through the C API.

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

show more ...

[Support] Fix some warnings when self-hosting clang on Windows

llvm-svn: 186413

Add a boolean parameter to the llvm::report_fatal_error() function to indicated
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.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

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

show more ...