| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|\ |
|
| | |
|
| |
| |
| |
| |
| | |
Since we are going to be using that function to also escape parameters
passed to transport proxies using environment variables.
|
| |
| |
| |
| |
| | |
This is in preparation for using tor_escape_str_for_socks_arg() to
escape server-side pluggable transport parameters.
|
|/
|
|
|
|
|
|
|
|
| |
This way, we don't have to use snprintf, which is not guaranteed to
be signal-safe.
(Technically speaking, strlen() and strlcpy() are not guaranteed to
be signal-safe by the POSIX standard. But I claim that they are on
every platform that supports libseccomp2, which is what matters
here.)
|
|
|
|
|
|
|
|
| |
Better tests for upper bounds, and for failing cases.
Also, change the function's interface to take a buffer length rather
than a maximum length, and then NUL-terminate: functions that don't
NUL-terminate are trouble waiting to happen.
|
|
|
|
|
| |
There are some other places in the code that will want a signal-safe
way to format numbers, so it shouldn't be static to util.c.
|
|
|
|
|
|
|
|
|
| |
The only thing that used format_helper_exit_status on win32 was the
unit tests. This caused an error when we tried to leave a static
format_helper_exit_status lying around in a production object file.
The easiest solution is to admit that this way of dealing with process
exit status is Unix-only.
|
|\
| |
| |
| |
| |
| |
| |
| | |
Conflicts:
src/common/include.am
Conflict was from adding testsupport.h near where sandbox.h had
already been added.
|
| |
| |
| |
| |
| |
| | |
This is not the most beautiful possible implementation (it requires
decorating mockable functions with ugly macros), but it actually
works, and is portable across multiple compilers and architectures.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If you pass the --enable-coverage flag on the command line, we build
our testing binaries with appropriate options eo enable coverage
testing. We also build a "tor-cov" binary that has coverage enabled,
for integration tests.
On recent OSX versions, test coverage only works with clang, not gcc.
So we warn about that.
Also add a contrib/coverage script to actually run gcov with the
appropriate options to generate useful .gcov files. (Thanks to
automake, the .o files will not have the names that gcov expects to
find.)
Also, remove generated gcda and gcno files on clean.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We previously used FILENAME_PRIVATE identifiers mostly for
identifiers exposed only to the unit tests... but also for
identifiers exposed to the benchmarker, and sometimes for
identifiers exposed to a similar module, and occasionally for no
really good reason at all.
Now, we use FILENAME_PRIVATE identifiers for identifiers shared by
Tor and the unit tests. They should be defined static when we
aren't building the unit test, and globally visible otherwise. (The
STATIC macro will keep us honest here.)
For identifiers used only by the unit tests and never by Tor at all,
on the other hand, we wrap them in #ifdef TOR_UNIT_TESTS.
This is not the motivating use case for the split test/non-test
build system; it's just a test example to see how it works, and to
take a chance to clean up the code a little.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is mainly a matter of automake trickery: we build each static
library in two versions now: one with the TOR_UNIT_TESTS macro
defined, and one without. When TOR_UNIT_TESTS is defined, we can
enable mocking and expose more functions. When it's not defined, we
can lock the binary down more.
The alternatives would be to have alternate build modes: a "testing
configuration" for building the libraries with test support, and a
"production configuration" for building them without. I don't favor
that approach, since I think it would mean more people runnning
binaries build for testing, or more people not running unit tests.
|
| | |
|
| | |
|
| | |
|
| | |
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| | |
It's controlled by the new Sandbox argument. Right now, it's rather
coarse-grained, it's Linux-only, and it may break some features.
|
|\ \ |
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/or/config.c
src/or/relay.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This implements "algorithm 1" from my discussion of bug #9072: on OOM,
find the circuits with the longest queues, and kill them. It's also a
fix for #9063 -- without the side-effects of bug #9072.
The memory bounds aren't perfect here, and you need to be sure to
allow some slack for the rest of Tor's usage.
This isn't a perfect fix; the rest of the solutions I describe on
codeable.
|
| | | |
| | | |
| | | |
| | | | |
This lets us have the possibility of fine-tuning the check in the tor_sscanf test cases at a later date.
|
|\| | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes bug 9047 (and some parts of 9031, 8922, 8883 that weren't
fixed in 8822). Bugfix on 0.2.2.6-alpha.
|
| | | |
| | | |
| | | |
| | | | |
tor_tls_evp_pkey_eq
|
|\| | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 884a0e269c382f9e927d8c8b1ef4ef9d2d48379d.
I'm reverting this because it doesn't actually make the problem go
away. It appears that instead we need to do unmap-then-replace.
|
|\| | | |
|
| |\ \ \ |
|
| | |/ /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
A comment by rransom on #8795 taken together with a comment by doorss
recorded on #2077 suggest that *every* attempt to replace the md cache
will fail on Vista/Win7 if we don't have the FILE_SHARE_DELETE flag
passed to CreateFile, and if we try to replace the file ourselves
before unmapping it. I'm adding the FILE_SHARE_DELETE, since that's
this simplest fix. Broken indexers (the favored #2077 hypothesis)
could still cause trouble here, but at least this patch should make us
stop stepping on our own feet.
Likely fix for #2077 and its numerous duplicates. Bugfix on
0.2.2.6-alpha, which first had a microdescriptor cache that would get
replaced before remapping it.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| |_|/
|/| | |
|
|\ \ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Also lower maximum interval without directory requests, and raise
maximum download tries.
Implements #6752.
|
|/ / /
| | |
| | |
| | | |
See #8792
|
|\| |
| | |
| | |
| | |
| | | |
Conflicts:
src/common/crypto.c
|
| | | |
|
| |\ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/or/dirserv.c
src/or/dirserv.h
src/test/test_dir.c
|
| | | | |
|