cypherpunks authored Dec 15, 2015 and Nick Mathewson committed Dec 15, 2015

On FreeBSD backtrace(3) uses size_t instead of int (as glibc does). This
causes integer precision loss errors when we used int to store its
results.

The issue is fixed by using size_t to store the results of backtrace(3).

The manual page of glibc does not mention that backtrace(3) returns
negative values. Therefore, no unsigned integer wrapping occurs when its
result is stored in an unsigned data type.

Because in 95 years, we or our successors will surely care about
enforcing the BSD license terms on this code.  Right?

Fixes windows compilation; bug not in any released Tor.

Bugfix on cc9e86db.

This involves some duplicate code between backtrace.c and sandbox.c,
but I don't see a way around it: calling more functions would mean
adding more steps to our call stack, and running clean_backtrace()
against the wrong point on the stack.

This meant moving a fair bit of code around, and writing a signal
cleanup function.  Still pretty nice from what I can tell, though.

We had accidentially grown two fake ones: one for backtrace.c, and one
for sandbox.c.  Let's do this properly instead.

Now, when we configure logs, we keep track of fds that should get told
about bad stuff happening from signal handlers.  There's another entry
point for these that avoids using non-signal-handler-safe functions.

On platforms with the backtrace/backtrace_symbols_fd interface, Tor
can now dump stack traces on assertion failure.  By default, I log
them to DataDir/stack_dump and to stderr.