src/or/connection.c: expose bucket_millis_empty for bufferevents test
Currently tor fails to build its test when enabled with bufferevents
because an #ifndef USE_BUFFEREVENTS hides bucket_millis_empty() and
friends. This is fine if we don't run tests, but if we do, we need
these functions in src/or/libtor-testing.a when linking src/test/test.
This patch moves the functions outside the #ifndef and exposes them.
configure.ac: fix build with --enable-bufferevents
When building with bufferevents enabled, configure.ac throws an
error if "$ac_cv_header_event2_bufferevent_ssl_h" is not set to
"yes". However, nowhere was AC_CHECK_HEADERS(event2/bufferevent_ssl.h)
done. This commit adds the check.
Nick Mathewson [Wed, 16 Jul 2014 08:05:00 +0000 (10:05 +0200)]
Add another 8387 diagnostic
When we run into bug 8387 (if we run into it again), report when we
last called circuit_expire_old_circuits_clientside(). This will let
us know -- if my fix for 8387 doesn't work -- whether my diagnosis
was at least correct.
On a non-blocking pipe fgets sets EAGAIN when it encounters partial lines. No
error is set on full lines or EOF. EOF is reached when the writing end of the
pipe is closed. Partial lines and full lines are both returned by fgets, EOF
results in NULL.
Mention of this behaviour can be found in #1903 and #2045.
Nick Mathewson [Fri, 20 Jun 2014 14:20:10 +0000 (10:20 -0400)]
Thread support is now required
Long ago we supported systems where there was no support for
threads, or where the threading library was broken. We shouldn't
have do that any more: on every OS that matters, threads exist, and
the OS supports running threads across multiple CPUs.
This resolves tickets 9495 and 12439. It's a prerequisite to making
our workqueue code work better, since sensible workqueue
implementations don't split across multiple processes.
Nick Mathewson [Mon, 16 Jun 2014 15:15:47 +0000 (11:15 -0400)]
manpage: Move more authority-only options into the authority section
I don't know whether we missed these or misclassified them when we
first made the "DIRECTORY AUTHORITY SERVER OPTIONS" section, but they
really belong there.
Nick Mathewson [Sat, 14 Jun 2014 15:46:54 +0000 (11:46 -0400)]
Add ATTR_UNUSED to HT_FIND
The fix for bug 8746 added a hashtable instance that never actually
invoked HT_FIND. This caused a warning, since we didn't mark HT_FIND
as okay-not-to-use.
Nick Mathewson [Wed, 30 Apr 2014 16:50:00 +0000 (12:50 -0400)]
More unit tests for process spawning
Try killing a running process; try noticing that a process has
exited without checking its output; verify that waitpid_cb (when
present) is set to NULL when you would expect it to be.
Nick Mathewson [Thu, 10 Apr 2014 15:16:42 +0000 (11:16 -0400)]
On Windows, terminate processes by handle, not pid
When we create a process yourself with CreateProcess, we get a
handle to the process in the PROCESS_INFO output structure. But
instead of using that handle, we were manually looking up a _new_
handle based on the process ID, which is a poor idea, since the
process ID might refer to a new process later on, but the handle
can't.
Nick Mathewson [Thu, 10 Apr 2014 15:06:10 +0000 (11:06 -0400)]
Use waitpid code to learn when a controlled process dies
This lets us avoid sending SIGTERM to something that has already
died, since we realize it has already died, and is a fix for the
unix version of #8746.
Nick Mathewson [Tue, 10 Jun 2014 17:35:45 +0000 (13:35 -0400)]
Try to diagnose bug 12184
Check for consistency between the queued destroy cells and the marked
circuit IDs. Check for consistency in the count of queued destroy
cells in several ways. Check to see whether any of the marked circuit
IDs have somehow been marked longer than the channel has existed.
Nick Mathewson [Wed, 11 Jun 2014 13:33:20 +0000 (09:33 -0400)]
Also raise the check for 0 circuit ID in created cell.
And add a comment about why conditions that would cause us to drop a
cell should get checked before actions that would cause us to send a
destroy cell.
Spotted by 'cypherpunks'.
And note that these issues have been present since 0.0.8pre1 (commit 0da256ef), where we added a "shutting down" state, and started
responding to all create cells with DESTROY when shutting down.
Nick Mathewson [Fri, 16 May 2014 14:32:31 +0000 (10:32 -0400)]
Replace last_added_nonpadding with last_had_circuits
The point of the "idle timeout" for connections is to kill the
connection a while after it has no more circuits. But using "last
added a non-padding cell" as a proxy for that is wrong, since if the
last circuit is closed from the other side of the connection, we
will not have sent anything on that connection since well before the
last circuit closed.
This is part of fixing 6799.
When applied to 0.2.5, it is also a fix for 12023.
Nick Mathewson [Wed, 9 Apr 2014 15:13:37 +0000 (11:13 -0400)]
Give each or_connection_t a slightly randomized idle_timeout
Instead of killing an or_connection_t that has had no circuits for
the last 3 minutes, give every or_connection_t a randomized timeout,
so that an observer can't so easily infer from the connection close
time the time at which its last circuit closed.
Also, increase the base timeout for canonical connections from 3
minutes to 15 minutes.
Nick Mathewson [Tue, 10 Jun 2014 16:04:06 +0000 (12:04 -0400)]
Improved diagnostic log for bug 8387.
When we find a stranded one-hop circuit, log whether it is dirty,
log information about any streams on it, and log information about
connections they might be linked to.
Nick Mathewson [Tue, 10 Jun 2014 15:11:47 +0000 (11:11 -0400)]
Avoid illegal read off end of an array in prune_v2_cipher_list
This function is supposed to construct a list of all the ciphers in
the "v2 link protocol cipher list" that are supported by Tor's
openssl. It does this by invoking ssl23_get_cipher_by_char on each
two-byte ciphersuite ID to see which ones give a match. But when
ssl23_get_cipher_by_char cannot find a match for a two-byte SSL3/TLS
ciphersuite ID, it checks to see whether it has a match for a
three-byte SSL2 ciphersuite ID. This was causing a read off the end
of the 'cipherid' array.
This was probably harmless in practice, but we shouldn't be having
any uninitialized reads.
(Using ssl23_get_cipher_by_char in this way is a kludge, but then
again the entire existence of the v2 link protocol is kind of a
kludge. Once Tor 0.2.2 clients are all gone, we can drop this code
entirely.)
Found by starlight. Fix on 0.2.4.8-alpha. Fixes bug 12227.
Nick Mathewson [Tue, 3 Jun 2014 22:19:08 +0000 (18:19 -0400)]
Fix ancient code that only checked circ_id, not circ_id and chan
This code mis-handled the case where a circuit got the same circuit
ID in both directions. I found three instances of it in the
codebase, by grepping for [pn]_circ_id.
Because of the issue in command_process_relay_cell(), this would
have made roughly one circuit in a million completely nonfunctional.
Nick Mathewson [Sun, 1 Jun 2014 20:48:43 +0000 (16:48 -0400)]
Avoid needless router_dir_info_has_changed from router_set_status
On some profiles of Andrea's from #11332, I found that a great deal
of time can still be attributed to functions called from
update_router_have_minimum_dir_info(). This is making our
digestmap, tor_memeq, and siphash functions take a much bigger
portion of runtime than they really should.
If we're calling update_router_have_minimum_dir_info() too often,
that's because we're calling router_dir_info_changed() too often.
And it looks like most of the callers of router_dir_info_changed()
are coming as tail-calls from router_set_status() as invoked by
channel_do_open_actions().
But we don't need to call router_dir_info_changed() so much! (I'm
not quite sure we need to call it from here at all, but...) Surely
we don't need to call it from router_set_status when the router's
status has not actually changed.
This patch makes us call router_dir_info_changed() from
router_set_status only when we are changing the router's status.
Fix for bug 12170. This is leftover from our fix back in 273ee3e81
in 0.1.2.1-alpha, where we started caching the value of
update_router_have_minimum_dir_info().
Nick Mathewson [Sun, 1 Jun 2014 18:02:55 +0000 (14:02 -0400)]
Use uint32 !=, not tor_memneq, for relay cell integrity checking
tor_memeq has started to show up on profiles, and this is one of the
most frequent callers of that function, appearing as it does on every
cell handled for entry or exit.
Nick Mathewson [Thu, 29 May 2014 15:21:17 +0000 (11:21 -0400)]
Start on the 0.2.5.5-alpha changelog.
I've copied the entries from changes/, labeled the ones that also
appeared in 0.2.4.22, sorted them lightly with a python script
(added to maint), and combined sections with the same name.
I didn't combine sections without a description (e.g. "Minor
bugfixes:"), since we'll probably add a description to those.
Nick Mathewson [Tue, 20 May 2014 20:57:47 +0000 (16:57 -0400)]
Postpone fetches based on should_delay_dir_fetch(), not DisableNetwork
Without this fix, when running with bridges, we would try fetching
directory info far too early, and have up to a 60 second delay if we
started with bridge descriptors available.
Fixes bug 11965. Fix on 0.2.3.6-alpha, arma thinks.
Nick Mathewson [Thu, 22 May 2014 21:39:36 +0000 (17:39 -0400)]
sandbox: revamp sandbox_getaddrinfo cacheing
The old cache had problems:
* It needed to be manually preloaded. (It didn't remember any
address you didn't tell it to remember)
* It was AF_INET only.
* It looked at its cache even if the sandbox wasn't turned on.
* It couldn't remember errors.
* It had some memory management problems. (You can't use memcpy
to copy an addrinfo safely; it has pointers in.)
This patch fixes those issues, and moves to a hash table.
projects / thirdparty / tor.git / log
