We used to try to use `process_vm_readv()` if `CAP_SYS_PTRACE` is
enabled. This avoided using signal handlers to catch crashes when
we try to read through an invalid pointer, but it complicates the
code and it turns out not to work on some Linux kernels where
the `process_vm_readv()` syscall is unavailable.
rdar://159930644
Musl's `clone()` wrapper returns `EINVAL` if you try to use `CLONE_THREAD`,
which seems a bit wrong (certainly it is in this particular application,
since we *really* don't care whether the thread is a valid C library
thread at this point).
Also properly support ELF images that are built with a base address other
than zero (this typically isn't an issue for dynamically linked programs,
as they will be relocated at runtime anyway, but for statically linked
binaries it's very common to set the base address to a non-zero value).
rdar://154282813
We should harden the output path setting so that it can't be used
as part of an exploit to get a crashing process to overwrite a
file at an attacker-controller path, or to divert the crash report
to `/dev/null` to hide their tracks or other such undesirable
activity.
Take a copy of the setting at start-up and write-protect it to
prevent attackers overwriting it.
Note that we already protect against attempts to trigger the
backtracer from privileged programs (both on Darwin and Linux);
this is really a belt and braces measure to make life harder for
attackers.
rdar://136977833
Add the ability to specify a filename or directory name as the output-to
setting in `SWIFT_BACKTRACE`. If the option is set to a directory name,
generate a unique filename in that directory using the process name,
process ID and timestamp.
rdar://136977833
Rather than just on or off, I've changed it to allow "off", "fast",
or "full". "fast" means that we'll do symbol lookup, but we won't
try to find inline frames and we won't run line number programs
(those are the things that are taking considerable time in some
cases).
rdar://122302117
Symbolication can take some time, depending on the binaries involved.
In certain contexts it's better for the backtrace to finish quickly,
and then symbolication could be done offline.
rdar://122302117
In the event that the backtracer fails to suspend a thread, it emits a
warning message. Unfortunately the exact meaning of this message isn't
obvious and it doesn't make clear that it's a secondary problem (that is,
you've already crashed at this point).
Update the message to make things clearer.
rdar://116593541
We shouldn't try to erase the message when in non-color mode; mostly
that's intended for redirected output scenarios anyway, and in that case
we don't really want garbage in the output.
Also, improve the failure messages when the backtracer itself goes
wrong or can't be executed.
Finally, change the behaviour slightly so that *if* we're explicitly
enabled, *and* the backtracer path wasn't explicitly specified, *and*
we can't find the backtracer, we print a warning on start-up. We
don't do that in any other case because we don't want spurious warnings
everywhere.
rdar://118055527
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
Thanks to a missing `-` sign, we were returning garbage rather than
indicating that the memory region in question was inaccessible. This
mainly affects register dumps (since that's the time we expect to have
to cope with out-of-bounds reads).
rdar://117900760
We have two stacks that we set up during crash handling, both of
which were potentially misaligned. This only tripped us up on
Ubuntu 20.04 on aarch64 - my guess is that maybe `clone()` aligns
the stack pointer on newer kernels which is why we didn't see it
on 22.04.
rdar://110743884
These seem to be related to signal handling issues in threads that
have been started presumably by the C library or some other library.
Primarily this appears to affect Ubuntu 20.04 on aarch64, though I
have seen sporadic issues on 18.04 as well.
We address the problem by making the thread suspension mechanism
more robust in the face of threads with masked signals.
rdar://110653167
Mike and Max made various helpful suggestions, so I've added and updated
various comments and amended the code to cope with partial reads and
writes.
rdar://110261430
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
