Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:14:30Zhttps://gitlab.torproject.org/legacy/trac/-/issues/23618"Bug: tor_compress_process: Non-fatal assertion"2020-06-13T15:14:30ZTrac"Bug: tor_compress_process: Non-fatal assertion"Getting many such messages since upgrading to Tor 0.3.2.1-alpha, on a client connected to a bridge running 0.3.2.1-alpha too:
```
Sep 21 21:00:16.000 [warn] tor_bug_occurred_(): Bug: ../src/common/compress.c:576: tor_compress_process: No...Getting many such messages since upgrading to Tor 0.3.2.1-alpha, on a client connected to a bridge running 0.3.2.1-alpha too:
```
Sep 21 21:00:16.000 [warn] tor_bug_occurred_(): Bug: ../src/common/compress.c:576: tor_compress_process: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed. (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: Non-fatal assertion !((rv == TOR_COMPRESS_OK) && *in_len == in_len_orig && *out_len == out_len_orig) failed in tor_compress_process at ../src/common/compress.c:576. Stack trace: (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x43) [0x557e14f28ba3] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb9) [0x557e14f43cd9] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_compress_process+0x14b) [0x557e14f4d50b] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x1a7745) [0x557e14f4d745] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_uncompress+0x31) [0x557e14f4dc01] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(connection_dir_reached_eof+0x1211) [0x557e14ed9301] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x10b259) [0x557e14eb1259] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(+0x51f0e) [0x557e14df7f0e] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(+0x229ba) [0x7f9a861109ba] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.1.so.6(event_base_loop+0x5a7) [0x7f9a86111537] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x28d) [0x557e14df8e5d] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(tor_main+0xe1d) [0x557e14dfbc6d] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x557e14df4699] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f9a849032e1] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x557e14df46ea] (on Tor 0.3.2.1-alpha )
Sep 21 21:00:16.000 [warn] More info on the bug: method == Zstandard compressed, finish == 0, *in_len == in_len_orig == 2878, *out_len == out_len_orig == 0
```
**Trac**:
**Username**: torvlnt33rhttps://gitlab.torproject.org/legacy/trac/-/issues/22883Bridge unavailable during differential consensus update2020-06-13T15:11:30ZTracBridge unavailable during differential consensus updateAfter updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all av...After updating Tor from 0.3.0.9 to 0.3.1.4 (on a Raspberry Pi running Raspbian), I observed that my bridge became unable to answer new connection requests for extended periods, from 10 to 20 minutes or more, while tor process uses all available cpu (more than 90% on average - with no corresponding traffic for clients) and files are updated in /var/lib/tor/diff-cache directory.
(For example, if I launch a TorBrowser using this bridge during such an update, it remains blocked before opening the Welcome window, and the corresponding client tor process remains blocked after "Bootstrapped 90%: Establishing a Tor circuit", for 10 minutes or more).
So I had to downgrade to 0.3.0.9, so that my bridge doesn't become unavailable for a total of several hours per day.
May I suggest that an option make it possible to choose between the new differential update mode and the traditional one?
First, this would be necessary for some (like me) to keep following new Tor versions long term.
And even on more powerful platforms, and even if a better handling of priorities could make it possible for main Tor thread to remain available on Pi, Tor relay operators might want to make different choices between minimizing bandwidth for consensus transfer or minimizing cpu usage, and hence power consumption. (Please think of the Planet globally, and not only of the network ;) )
**Trac**:
**Username**: torvlnt33rTor: 0.3.1.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/legacy/trac/-/issues/21771Cannot change bridge (with Tor 0.3.0.4-rc)2020-06-13T15:07:22ZTracCannot change bridge (with Tor 0.3.0.4-rc)Trying to replace a bridge in torrc (that had been successfully used for a long time) with another one results in many warnings "[warn] Failed to find node for hop 0 of our path. Discarding this circuit.", and failure to connect.
Only w...Trying to replace a bridge in torrc (that had been successfully used for a long time) with another one results in many warnings "[warn] Failed to find node for hop 0 of our path. Discarding this circuit.", and failure to connect.
Only way out found is to edit "state" file and remove the "Guard" line for the previous bridge (with "listed=0"), or come back to previous bridge option in torrc.
I found this while testing further after reporting what I initially thought was a bug in TorBrowser (https://trac.torproject.org/projects/tor/ticket/21768)
**Trac**:
**Username**: torvlnt33rTor: 0.3.1.x-finalGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/legacy/trac/-/issues/8028Decide how to sanitize ntor-onion-key lines in bridge descriptors2020-06-13T17:50:08ZTracDecide how to sanitize ntor-onion-key lines in bridge descriptorsSince upgrading to Tor 0.2.4.9-alpha, my bridges do not appear with correct information in https://onionoo.torproject.org/details?type=bridge:
- platform is either not present or still appears as "Tor 0.2.4.7-alpha on Linux". Note that, ...Since upgrading to Tor 0.2.4.9-alpha, my bridges do not appear with correct information in https://onionoo.torproject.org/details?type=bridge:
- platform is either not present or still appears as "Tor 0.2.4.7-alpha on Linux". Note that, globally, no bridge is reported as running version 0.2.4.9, which is quite unlikely.
- advertised_bandwidth is either not present or 0,
- last_restarted is either not present or still the previous time from when previous version 0.2.4.7 was last restarted.
When downgrading to 0.2.4.7 (thanks to Debian snapshot), advertised_bandwidth moves away from 0, last_restarted and platform are correct again.
**Trac**:
**Username**: torvlnt33rKarsten LoesingKarsten Loesinghttps://gitlab.torproject.org/legacy/trac/-/issues/21768Problem changing bridge in TorBrowser 7.0a22020-06-13T15:07:22ZTracProblem changing bridge in TorBrowser 7.0a2Here is a bug observed with TorBrowser 7.0a2 (which may have been there before), maybe linked to the interaction with the new guard algorithm:
- after replacing a first bridge with one other bridge, through the "Configure" dialog, TorBr...Here is a bug observed with TorBrowser 7.0a2 (which may have been there before), maybe linked to the interaction with the new guard algorithm:
- after replacing a first bridge with one other bridge, through the "Configure" dialog, TorBrowser fails to connect, with many error messages: "[warn] Failed to find node for hop 0 of our path. Discarding this circuit."
- to work with bridges again, need to erase manually the "Guard" line of first bridge in state file (with "listed=0" and "unlisted_since=..."), or put back first bridge (to get "listed=1").
**Trac**:
**Username**: torvlnt33r