Before a couple weeks ago didn't know Tor had these tests, interesting! Stem
already has tests for spawning tor processes but lacked any with this targeted
focus on its arguments.
I've added our own counterpart for these tests. Many are direct copies but
there were others I improved a little...
https://trac.torproject.org/projects/tor/ticket/14109https://gitweb.torproject.org/stem.git/commit/?id=137d193a026638f066e817e3396cebbbb6ace012
Now that Tor uses Stem to supplement its tests no reason for these to live
separately. Tested by simply building tor and confirming test_cmdline_args.py
is no longer in the generated Makefile.
In #14803, Damian noticed that his Tor sometimes segfaults. Roger noted
that his valgrind gave an invalid write of size one here. Whenever we
use FLEXIBLE_ARRAY_MEMBER, we have to make sure to actually malloc a
thing that's large enough.
Fixes bug #14803, not in any released version of Tor.
If the guard unreachable_since variable was set, the status "up" was
reported which is wrong. This adds the "down" status followed by the
unreachable_since time value.
Fixes#14184
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
David Goulet finds that when he runs a busy relay for a while with the
latest version of the git code, the number of onionskins handled
slowly dwindles to zero, with total_pending_tasks wedged at its
maximum value.
I conjecture this is because the total_pending_tasks variable isn't
decremented when we successfully cancel a job. Fixed that.
Fixes bug 14741; bugfix not on any released version of tor.
This both fixes the problem, and ensures that forgetting to update
domain_list in the future will trigger the bug codepath instead of
a NULL pointer deref.
Ordinarily, get_options() can never return NULL, but with
test_status.c mocking, it can. So test for that case.
The best fix here would be to pass the options value to a
bridge_server_mode() function.
After connectivity problems, only try connecting to bridges which
are currently configured; don't mark bridges which we previously
used but are no longer configured. Fixes 14216. Reported by
and fix provided by arma.
If the returned value of read/recv is 0 (meaning EOF), we'll end up in an
infinite loop (active wait) until something is written on the pipe which is
not really what we want here especially because those functions are called
from the main thread.
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
