Warning: Failed to confirm worker threads' start up after timeout.
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(_start+0x2a) [0x56404d21ddaa] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(cpuworker_init+0x53) [0x56404d373d53] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(log_backtrace_impl+0x57) [0x56404d29e1f7] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(main+0x19) [0x56404d21dd59] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(run_tor_main_loop+0xce) [0x56404d22188e] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(threadpool_new+0x295) [0x56404d3e28f5] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(tor_assertion_failed_+0x148) [0x56404d2a9248] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(tor_main+0x49) [0x56404d21e179] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /builds/tpo/core/tor/build/src/app/tor(tor_run_main+0x1e5) [0x56404d221db5] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea) [0x7f6aa3b1cd7a] (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
Warning: Bug: Tor 0.4.9.0-alpha-dev (git-4f3aafa1e422e9aa): Assertion 0 failed in threadpool_new at /builds/tpo/core/tor/src/lib/evloop/workqueue.c:641: . Stack trace: (on Tor 0.4.9.0-alpha-dev 4f3aafa1e422e9aa)
We are figuring it out but revert this so we can release an alpha.
Jim Newsome [Fri, 15 Nov 2024 00:38:22 +0000 (18:38 -0600)]
test-network: include IPv6 tests unconditionally
Previously we would incorrectly detect that ipv6 isn't supported if the
ping binary isn't present (as it may not be in a relatively stripped
down container image), or if ICMP packets aren't permitted (as they
often aren't in containers).
We don't really have a need to run these network tests on non-IPv6
systems, so it makes more sense to just run them unconditionally.
Jim Newsome [Wed, 30 Oct 2024 15:34:58 +0000 (10:34 -0500)]
CI: use a fixed version of chutney
While chutney currently runs tor's chutney test in its own CI,
it's difficult to guarantee the two won't accidentally diverge.
Probably best to use a fixed version here so that we can control
chutney version bumps and avoid surprise breakage in tor's CI.
This will also free us to intentionally make breaking changes in
chutney (though I don't have any immediate plans for any).
Roger Dingledine [Tue, 15 Oct 2024 06:54:27 +0000 (02:54 -0400)]
don't build preemptive conflux circuits if no predicted ports
Conflux circuit building was ignoring the "predicted ports" feature,
which aims to make Tor stop building circuits if there have been
no user requests lately. This bug led to every idle Tor on the
network building and discarding circuits every 30 seconds, which
added overall load to the network, used bandwidth and battery from
clients that weren't actively using their Tor, and kept sockets open
on guards which added connection padding essentially forever.
Bug went in on commit 39c2927d when we added preemptive conflux circuit
pools.
Resources allocated by cpuworker weren't being freed on clean shutdown.
This applies for worker threads, worker thread pool, reply queue, reply
event, ...
Nick Mathewson [Mon, 9 Sep 2024 21:00:50 +0000 (17:00 -0400)]
Implement proposal 351
This proposal adds new syntax to the SOCKS5 username/password extension scheme,
so that requests with usernames starting with <torS0X> are now reserved.
For C tor, all we need to do is reject every username starting with <torS0X>
unless it is exactly "<torS0X>0".
Alexander Færøy [Fri, 21 Jul 2023 00:11:16 +0000 (02:11 +0200)]
Add implementation and version metadata to bridge extra-info.
This patch adds two new keys to bridges' extra-info document:
"transport-version" and "transport-implementation".
These two new values always appear together (if one is missing, the
other one will be missing too) and is parsed from PT's STATUS
TYPE=version messages.
Alexander Færøy [Thu, 24 Mar 2022 19:13:41 +0000 (19:13 +0000)]
Add support for PT STATUS TYPE=version messages.
This patch adds support for handling the version status message. Once we
receive such message, we add the given version string to the
managed_proxy_t instance. Note this value can be NULL and the value can
change throughout the lifetime of the PT as multiple status version
messages are handled.