The "was already deallocated" message is incorrect, since the target of an unowned reference stays allocated even after being deinitialized. We could say "was already deinitialized" but that's a bit of a niche term. "Was already destroyed" conveys what happened without the reader needing to worry about deinitialization versus deallocation.
rdar://149237704
It's hard to tell why a crash occurred with just "Could not allocate memory." Modify the message to include the size/alignment, which will help distinguish between an actual lack of memory and a request for an excessively large allocation.
While we're in there, add \n to a bunch of other fatal error helper functions that didn't have it.
This prepares the runtime to be closed with its dependencies when
performing static linking. The pragma ensures that the linker will
automatically pick up the dependent libraries avoiding the need to
explicitly add the dependencies.
Fix an unused variable warning in `Errors.cpp`.
Use brace initialization syntax in `SymbolInfo.cpp` rather than using
a constructor call.
rdar://130992923
We were calling `SymInitialize()` multiple times, which is wrong, which
was making the `SymbolInfo::lookup()` call fail. Also, we weren't
fetching the module names, so we should do that too.
rdar://130992923
This introduces a non-Darwin (non-CrashReporter) storage for error
messages to allow extraction for crash reporting. This is initially
meant to be used on Windows, though it is generic enough to be used on
any platform.
ASL is deprecated in macOS 10.12. It may be time to transition to os_log now
that deployment targets have been raised to 10.12, but until that project
starts these warnings are just pollution.
Filed rdar://121066531 to track adoption of `os_log()` if appropriate.
When we crash, emit a message straight away that says we're working
on a backtrace. If starting the backtracer fails, report that also.
Finally, add a duration to the messages output by the backtracer, so
that we can see how long it took.
rdar://118055527
There's no need for fatalError() to try to generate its own backtraces
when the runtime's backtracer is enabled. Not only is the code it uses
more fragile but it also doesn't support async or inline frames and it
can't look-up symbols properly either.
rdar://117470489
Fix the issue that fatal errors in certain cases don't terminate the
process and the process keeps running in Windows by disabling the
exception swallowing that supressed the illegal instruction exceptions
coming from llvm.trap.
This also adds a function to demangle a symbol, and a way for the
backtracing code to report warning messages to the same place as
the main runtime.
I'd like to rename the _swift_isThunkFunction() SPI also, but we
can't do that until we've made the changes to the _Backtracing
library, so we'll do that there instead.
rdar://110261430
On Linux it seems that the linker objects, probably because of link order,
to the definition of `swift::threading::fatal()` being in both static
libraries. Fix by moving `swift::threading::fatal()` to its own file
in the main runtime as well as the Concurrency runtime.
Fixes#59444.
We shouldn't include <windows.h> implicitly from .cpp files, but should
do it directly so that we know it's there.
Also, if we're including <windows.h>, do it at the top of the file.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
We shouldn't include <windows.h> implicitly from .cpp files, but should
do it directly so that we know it's there.
Also, if we're including <windows.h>, do it at the top of the file.
rdar://90776105
Moved all the threading code to one place. Added explicit support for
Darwin, Linux, Pthreads, C11 threads and Win32 threads, including new
implementations of Once for Linux, Pthreads, C11 and Win32.
rdar://90776105
Moved the _gCRAnnotations declarations to their own object module,
which will help to avoid duplicate symbol problems (at least with .a
files).
Also tweaked things to make it so that the demangler and runtime
versions of the message setting code will interoperate (and so that
they'll interoperate better with other implementations that might
creep in from somewhere, like the one in LLVMSupport).
rdar://91095592
The demangling library can't use the error handling from the main runtime
because it isn't always linked with it. However, it's useful to have
some error handling, and in particular to be able to get data into the
crash logs.
This is complicated because of the way the demangling library gets used,
the upshot of which is that I've had to add a second object library just
for libswiftCore's use, so that the demangler will use the runtime's
error handling functions when present, and fall back on its own when
they aren't.
rdar://89139049
Replace the `static std::mutex` with Swift's `StaticMutex` so that we
avoid triggering an error due to an exit time destructor. Repairs the
build after #38562.
Rather than using the forward declaration for the LLVMSupport types,
expect to be able to use the full declaration. Because these are
references in the implementation, there is no reason to use a forward
declaration as the full types need to be declared for use. The LLVM
headers will provide the declaration and definition for the types. This
is motivated by the desire to ensure that the LLVMSupport symbols are
properly namespaced to avoid ODR violations in the runtime.
This replaces `LLVM_LIBRARY_VISIBILITY` with `SWIFT_LIBRARY_VISIBILTIY`
througout the runtime. The purpose of this attribution is unclear -
building with `-fvisibility=hidden` would accomplish this. This is an
entirely mechanical change replacing the macro with the Swift namespaced
variant instead.
