| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
It's possible for two threads to hit assertion failures at the same
time. If that happens, let's keep them from stomping on the same
cb_buf field.
Fixes bug 11048; bugfix on 0.2.5.2-alpha. Reported by "cypherpunks".
|
| | |
|
| | |
|
| |
|
|
|
|
| |
With any luck, this will clean up errors where we detect that
REG_{EIP,RIP} is present in autoconf, but when we go to include it,
it isn't there.
|
| | |
|
| |
|
|
|
| |
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.
|