Stop attempting to unconditionally mirror the tor repository in GitLab
CI.  This prevented developers from enabling GitLab CI on master
because the "update" job would attempt to run, causing an unuseful CI
failure.  Fixes bug 23755.

Skip test_config_include_no_permission() when running as root, because
it will get an unexpected success from config_get_lines_include().
This affects some continuous integration setups.  Fixes bug 23758.

cathugger authored 7 years ago and David Goulet committed 7 years ago

Fixes #23748

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

Signed-off-by: David Goulet <dgoulet@torproject.org>

David Goulet authored 7 years ago and Nick Mathewson committed 7 years ago

Signed-off-by: David Goulet <dgoulet@torproject.org>

Add more explanation in doc/HACKING about how to read gcov output,
including a reference to the gcov documentation in the GCC manual.
Also add details about how our postprocessing scripts modify gcov
output.

These are related to handling of failures on functions which can't
fail.

We do that because we want to use the path fraction dirinfo data in case
we are missing primary guard dirinfo.

In scripts/test/coverage, avoid attempting to move gcov output files
to the root directory when given no arguments.  Fixes bug 23741.

Alexander Hansen Færøy authored 7 years ago and Isis Lovecruft committed 7 years ago

Signed-off-by: Isis Lovecruft <isis@torproject.org>

When we added HTTPTunnelPort, the answer that we give when you try
to use your SOCKSPort as an HTTP proxy became wrong.  Now we explain
that Tor sorta _is_ an HTTP proxy, but a SOCKSPort isn't.

I have left the status line the same, in case anything is depending
on it.  I have removed the extra padding for Internet Explorer,
since the message is well over 512 bytes without it.

Fixes bug 23678; bugfix on 0.3.2.1-alpha.

Because our monotonic time interface doesn't play well with value set to 0,
always initialize to now() the scheduler_last_run at init() of the KIST
scheduler.

Fixes #23696

Signed-off-by: David Goulet <dgoulet@torproject.org>

Matt Traudt authored 7 years ago and David Goulet committed 7 years ago

When a channel is scheduled and flush cells returns 0 that is no cells to
flush, we flag it back in waiting for cells so it doesn't get stuck in a
possible infinite loop.

It has been observed on moria1 where a closed channel end up in the scheduler
where the flush process returned 0 cells but it was ultimately kept in the
scheduling loop forever. We suspect that this is due to a more deeper problem
in tor where the channel_more_to_flush() is actually looking at the wrong
queue and was returning 1 for an empty channel thus putting the channel in the
"Case 4" of the scheduler which is to go back in pending state thus
re-considered at the next iteration.

This is a fix that allows the KIST scheduler to recover properly from a not
entirelly diagnosed problem in tor.

Fixes #23676

Signed-off-by: David Goulet <dgoulet@torproject.org>

When we added single_conn_free_bytes(), we cleared the outbuf on a
connection without setting outbuf_flushlen() to 0.  This could cause
an assertion failure later on in flush_buf().

Fixes bug 23690; bugfix on 0.2.6.1-alpha.

This caused a BUG log when we noticed that the circuit had no
channel.  The likeliest culprit for exposing that behavior is
d769cab3, where we made circuit_mark_for_close() NULL out
the n_chan and p_chan fields of the circuit.

Fixes bug 8185; bugfix on 0.2.5.4-alpha, I think.