Only some very ancient distributions don't ship with Libevent 2 anymore,
even the oldest supported Ubuntu LTS version has it. This allows us to
get rid of a lot of compat code.
This is a big-ish patch, but it's very straightforward. Under this
clang warning, we're not actually allowed to have a global variable
without a previous extern declaration for it. The cases where we
violated this rule fall into three roughly equal groups:
* Stuff that should have been static.
* Stuff that was global but where the extern was local to some
other C file.
* Stuff that was only global when built for the unit tests, that
needed a conditional extern in the headers.
The first two were IMO genuine problems; the last is a wart of how
we build tests.
Previously, we had done this only in the connection_free() case, but
when we called connection_free_() directly from
connections_free_all(), we didn't free the connections.
Libevent uses an arc4random implementation (I know, I know) to
generate DNS transaction IDs and capitalization. But it liked to
initialize it either with opening /dev/urandom (which won't work
under the sandbox if it doesn't use the right pointer), or with
sysctl({CTL_KERN,KERN_RANDOM,RANDOM_UUIC}). To make _that_ work, we
were permitting sysctl unconditionally. That's not such a great
idea.
Instead, we try to initialize the libevent PRNG _before_ installing
the sandbox, and make sysctl always fail with EPERM under the
sandbox.
In a couple of places, to implement the OOM-circuit-killer defense
against sniper attacks, we have counters to remember the age of
cells or data chunks. These timers were based on wall clock time,
which can move backwards, thus giving roll-over results for our age
calculation. This commit creates a low-budget monotonic time, based
on ratcheting gettimeofday(), so that even in the event of a time
rollback, we don't do anything _really_ stupid.
A future version of Tor should update this function to do something
even less stupid here, like employ clock_gettime() or its kin.
This is meant to avoid conflict with the built-in log() function in
math.h. It resolves ticket 7599. First reported by dhill.
This was generated with the following perl script:
#!/usr/bin/perl -w -i -p
s/\blog\(LOG_(ERR|WARN|NOTICE|INFO|DEBUG)\s*,\s*/log_\L$1\(/g;
s/\blog\(/tor_log\(/g;
It looks like there was a compilation error for 6826 on some
platforms. Removing even more now-uncallable code to handle detecting
libevent versions before 1.3e.
Fixes bug 8012; bug not in any released Tor.
This won't actually break them any worse than they were broken before:
it just removes a set of warnings that nobody was actually seeing, I
hope.
Closes 6826
Also, try to resolve some doxygen issues. First, define a magic
"This is doxygen!" macro so that we take the correct branch in
various #if/#else/#endifs in order to get the right documentation.
Second, add in a few grouping @{ and @} entries in order to get some
variables and fields to get grouped together.
This commit is completely mechanical; I used this perl script to make it:
#!/usr/bin/perl -w -i.bak -p
if (/^\s*\#/) {
s/MS_WINDOWS/_WIN32/g;
s/\bWIN32\b/_WIN32/g;
}
This is a fancier bug4457 workaround for 0.2.3. In 0.2.2, we could
just tell Libevent "Don't enable locking!" so it wouldn't try to make
the event_base notifiable. But for IOCP, we need a notifiable base.
(Eventually, we'll want a notifiable base for other stuff, like
multithreaded crypto.) So the solution is to try a full-featured
initialization, and then retry with all the options turned off if that
fails.
Conflicts:
src/common/compat_libevent.c
Resolving conflict by not taking 7363eae13c ("Use the
EVENT_BASE_FLAG_NOLOCK flag to prevent socketpair() invocation"): in
Tor 0.2.3.x, we _do_ sometimes use notifiable event bases.
