motivation: catch up to fixes and improvments in underlying library
changes:
* vendor latest version of libbacktrace
* update vendoring script to exclude some new files that are not needed
Motivation:
Previously, we would use
`CommandLine.arguments[0]`/`argv[0]`/`getexecname()` as the preferred
ways to find the main binary. That sounds sensible, especially given
the fact that we'd fall back onto other methods (such as
`/proc/self/exe`) when the previous ones don't work.
There is however an unfortunate edge case. If you for example have your
app binary at `/app/app` and you start it with a relative path `./app`
from within `/app`, then `CommandLine.arguments[0]` will only contain
`./app`. If now the app changes its working directory to `/`, `./app`
would mean `/app` which is the directory. This would mean we will find
the target but instead of the binary we'd find the directory `/app`.
From then on, everything else fails.
A similar problem is if `argv[0]` was actually set incorrectly when
`exec*`ing the process. This has happened at least in one instance.
Modification:
Given that we only target Linux here, we can actually here, we can
change the order in which we try to find the main binary. We can start
by using `/proc/self/exe` which is a very high quality and almost
guaranteed to work way to find the main binary, nevermind the
information in `argv`.
Result:
More robust symbolications, especially in environments like Heroku/Dokku
where we've seen `argv` not being set correctly.
Motivation:
In case SwiftBacktrace fails, we get only very little output.
Unfortunately, some crucial information (like the errno) is missing and
in case `mmap` fails, we don't know if the problem is file I/O or
allocating memory.
Modification:
- print errnos
- distinguish the two mmaps
Result:
Easier debugging
tomer doron
Johannes Weiss
Johannes Weiss
Ian Partridge