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

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.

My current theory is that this is just a marked circuit that hasn't
closed yet, but let's gather more information in case that theory is
wrong.

Diagnostic for 8185.

AddressSanitizer found a leak in test_util_decompress_dos_impl().
Fixes bug #23691.

This patch ensures that we return TOR_COMPRESS_BUFFER_FULL in case we
have a input bytes left to process, but are out of output buffer or in
case we need to finish where the compression implementation might need
to write an epilogue.

See: https://bugs.torproject.org/23551

See: https://bugs.torproject.org/23551

This patch ensures that we return TOR_COMPRESS_BUFFER_FULL in case we
have a input bytes left to process, but are out of output buffer or in
case we need to finish where the compression implementation might need
to write an epilogue.

See: https://bugs.torproject.org/23551

These tests try uncompressing garbage, verify that we won't
make compression bombs, and verify that we won't uncompress
compression bombs.

Apparently, my compiler now generates coverage markers for
label-only lines, so we need to exclude those too if they are meant
to be unreachable.

There was some coverage before, but it was mostly accidental.

Coverage is now respectable. :)

We use these when we're acting as a SOCKS client, but we'd never
actually written tests for them :/

These tests aren't reachable, given their actual arguments.  I'm
going to mark them as BUG(), and as unreachable with LCOV.

Many of the 'truncated command' paths in fetch_from_buf_socks() were
not reached by the tests.  This new unit test tries to check them
exhaustively.

No other code changes.