Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:51:16Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28995Fix the IPv6 case of tor_ersatz_socketpair2020-06-27T13:51:16ZTracFix the IPv6 case of tor_ersatz_socketpairIn `get_local_listener` which is used by `tor_ersatz_socketpair`, `sin6_family` is currently being set to `AF_INET` in the IPv6 case when `AF_INET6` should be used instead.
This code was introduced in commit 9b24609af003cb79091e628c179c...In `get_local_listener` which is used by `tor_ersatz_socketpair`, `sin6_family` is currently being set to `AF_INET` in the IPv6 case when `AF_INET6` should be used instead.
This code was introduced in commit 9b24609af003cb79091e628c179cf617ff41aae7 from this past August, so this is not a brand-new problem.
I tested this on my OpenBSD box by forcing an IPv6 socket to be used for `tor_ersatz_socketpair` and running the test suite. There is a test in the test suite that tests `tor_ersatz_socketpair`: it (of course) fails using the current `AF_INET` code but it passes when using `AF_INET6` instead.
PR to follow to change `AF_INET` to `AF_INET6` in the IPv6 case.
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28992Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion ...2021-06-23T17:26:03ZtraumschuleBug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed.(likely follow-up of legacy/trac#28669)
```
Jan 04 06:53:53.620 [notice] Your system clock just jumped 21357 seconds forward; assuming established circuits no longer work.
Jan 04 06:55:05.286 [warn] tor_bug_occurred_(): Bug: ../src/feat...(likely follow-up of legacy/trac#28669)
```
Jan 04 06:53:53.620 [notice] Your system clock just jumped 21357 seconds forward; assuming established circuits no longer work.
Jan 04 06:55:05.286 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:05.287 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.522 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.523 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
J
Jan 04 06:55:56.569 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.570 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
J
Jan 04 06:55:56.613 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 06:55:56.615 [warn] Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
...
Jan 04 08:48:21.767 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:571: send_introduce1: Non-fatal assertion !(ip == NULL) failed. (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.772 [warn] Bug: Non-fatal assertion !(ip == NULL) failed in send_introduce1 at ../src/feature/hs/hs_client.c:571. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x65) [0x681d35] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x67d55d] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x23c) [0x58070c] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x797) [0x514317] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x171) [0x517b61] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x82) [0x580d92] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x235) [0x5cb345] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0xa0c04) [0x532c04] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x38a) [0x53515a] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(command_process_cell+0x181) [0x515111] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x34a) [0x4f9cea] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x8beed) [0x51deed] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x4a931) [0x4dc931] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(connection_handle_read+0x9a4) [0x4e6784] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x5ab79) [0x4ecb79] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/lib/i386-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7d1) [0xb7619681] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x61dfe0] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(do_main_loop+0xc5) [0x4edfe5] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(run_tor_main_loop+0x1ce) [0x4d996e] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_run_main+0x11c5) [0x4dad25] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(tor_main+0x3f) [0x4d7ebf] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(main+0x35) [0x4d7a15] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb6f65b41] (on Tor 0.4.0.0-alpha-dev )
Jan 04 08:48:21.773 [warn] Bug: /usr/bin/tor(+0x45a71) [0x4d7a71] (on Tor 0.4.0.0-alpha-dev )
```Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/28981Use HW_PHYSMEM in get_total_system_memory_impl2020-06-27T13:51:17ZTracUse HW_PHYSMEM in get_total_system_memory_implAn upcoming PR will change `get_total_system_memory_impl` to use `HW_PHYSMEM` instead of `HW_USERMEM` in the case where `HW_PHYSMEM` is defined but some other methods are not available for getting the total physical memory (one example: ...An upcoming PR will change `get_total_system_memory_impl` to use `HW_PHYSMEM` instead of `HW_USERMEM` in the case where `HW_PHYSMEM` is defined but some other methods are not available for getting the total physical memory (one example: FreeBSD).
The code actually checks that `HW_PHYSMEM` is defined, and comments reference `HW_PHYSMEM`, but `HW_USERMEM` is simply used instead.
For OpenBSD, NetBSD and OSX a 64-bit variant of `HW_PHYSMEM` is used when available.
The same PR will also contain a commit to update/fix a couple of comments in this same file. It will fix a typo in a comment and update another comment which suggests that `HW_PHYSMEM64` is something only on OpenBSD when NetBSD actually defines it as well.
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28979Current alpha manual typo authorized_clients2021-07-22T16:20:05ZTracCurrent alpha manual typo authorized_clientsManual text, key word `Client Authorization` mentions `public-key` vs `privkey` for service:
```
To configure client authorization on the service side, the "<HiddenServiceDir>/authorized_clients/" directory needs to exist. Each file in t...Manual text, key word `Client Authorization` mentions `public-key` vs `privkey` for service:
```
To configure client authorization on the service side, the "<HiddenServiceDir>/authorized_clients/" directory needs to exist. Each file in that directory should be suffixed with ".auth" (i.e. "alice.auth"; the file name is irrelevant) and its content format MUST be:
<auth-type>:<key-type>:<base32-encoded-public-key>
The supported <auth-type> are: "descriptor". The supported <key-type> are: "x25519". The <base32-encoded-privkey> is the base32 representation of the raw key bytes only (32 bytes for x25519).
```
rend-spec-v3.txt (4329f00194bdb7adff2c9daa1cf47b09ce4c2a9e) confirms `public-key` instead of `privkey`.
So `privkey` is wrong for service.
**Trac**:
**Username**: FelixixTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28974android compiling error: 'errno' undeclared (first use in this function)2020-06-27T13:51:17ZNathan Freitasandroid compiling error: 'errno' undeclared (first use in this function)make all-am
make[1]: Entering directory '/home/n8fr8/dev/repos/tor-android/external/tor'
CC src/lib/fs/freespace.o
src/lib/fs/freespace.c: In function 'tor_get_avail_disk_space':
src/lib/fs/freespace.c:59:3: error: 'errno' undec...make all-am
make[1]: Entering directory '/home/n8fr8/dev/repos/tor-android/external/tor'
CC src/lib/fs/freespace.o
src/lib/fs/freespace.c: In function 'tor_get_avail_disk_space':
src/lib/fs/freespace.c:59:3: error: 'errno' undeclared (first use in this function)
errno = ENOSYS;
^
src/lib/fs/freespace.c:59:3: note: each undeclared identifier is reported only once for each function it appears in
src/lib/fs/freespace.c:59:11: error: 'ENOSYS' undeclared (first use in this function)
errno = ENOSYS;
^
Makefile:9083: recipe for target 'src/lib/fs/freespace.o' failed
make[1]: *** [src/lib/fs/freespace.o] Error 1
make[1]: Leaving directory '/home/n8fr8/dev/repos/tor-android/external/tor'
Makefile:5000: recipe for target 'all' failed
make: *** [all] Error 2Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28970tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_ke...2021-06-23T17:26:03ZTractor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertionIf this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received rel...If this is duplicate I'm sorry, but I found nothing similar in old tickets. `Sandbox` is 1 in `torrc`. Set priority and severity of this ticket to appropriate values if it is not so critical.
```
Jan 01 05:31:32.000 [notice] Received reload signal (hup). Reloading config and resetting internal state.
Jan 01 05:31:32.000 [notice] Read configuration file "/usr/share/tor/tor-service-defaults-torrc".
Jan 01 05:31:32.000 [notice] Read configuration file "/etc/tor/torrc".
Jan 01 05:31:32.000 [notice] Tor 0.3.4.9 (git-074ca2e0054fded1) opening log file.
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:624: setup_intro_circ_auth_key: Non-fatal assertion !(desc == NULL) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(desc == NULL) failed in setup_intro_circ_auth_key at ../src/or/hs_client.c:624. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_circuit_has_opened+0x2ca) [0x56345ce8027a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_send_next_onion_skin+0x372) [0x56345cdfd192] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x78fc3) [0x56345cd92fc3] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] tor_bug_occurred_(): Bug: ../src/or/hs_client.c:443: intro_circ_is_ok: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed. (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: Non-fatal assertion !(!hs_ident_intro_circ_is_valid(circ->hs_ident)) failed in intro_circ_is_ok at ../src/or/hs_client.c:443. Stack trace: (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(log_backtrace+0x42) [0x56345cea26e2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xb7) [0x56345cebd587] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_send_introduce1+0x352) [0x56345ce7fda2] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_handshake_attach_circuit+0x33c) [0x56345ce1126c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_ap_attach_pending+0x1a0) [0x56345ce31cb0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(hs_client_receive_rendezvous_acked+0x79) [0x56345ce803c9] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(rend_process_relay_cell+0x28b) [0x56345cd9c2cb] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x791f7) [0x56345cd931f7] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(circuit_receive_relay_cell+0x311) [0x56345cd95211] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(command_process_cell+0x280) [0x56345ce126f0] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(channel_tls_handle_cell+0x273) [0x56345cdf4493] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x11de1c) [0x56345ce37e1c] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(connection_handle_read+0x892) [0x56345ce2e822] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x53a61) [0x56345cd6da61] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x7fc) [0x7f2c7be623dc] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x25f) [0x56345cd6fe3f] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x1165) [0x56345cd72315] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x56345cd6a32a] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x56345cd6a099] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7f2c7a7e6b45] (on Tor 0.3.4.9 )
Jan 01 05:31:33.000 [warn] Bug: /usr/bin/tor(+0x500e9) [0x56345cd6a0e9] (on Tor 0.3.4.9 )
```
Tor on Linux. Is it related to legacy/trac#27471 or legacy/trac#19926?
**Trac**:
**Username**: torcrashTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/28938Fix incorrect OpenBSD macro tests (fix testsuite failure)2020-06-27T13:51:19ZTracFix incorrect OpenBSD macro tests (fix testsuite failure)The testsuite has been failing on OpenBSD, but an upcoming PR will fix this.
It was previously decided (ticket legacy/trac#20980) that the `OpenBSD` macro would be used to test for OpenBSD (rather than `__OpenBSD__`, etc.) because the f...The testsuite has been failing on OpenBSD, but an upcoming PR will fix this.
It was previously decided (ticket legacy/trac#20980) that the `OpenBSD` macro would be used to test for OpenBSD (rather than `__OpenBSD__`, etc.) because the former seems to be defined on OpenBSD forks when the latter may or may not be.
However, `sys/param.h` needs to be included for this macro to be defined. There were many files where `OpenBSD` was tested for, but when `sys/param.h` was not included.
An upcoming PR will contain a fix to include `sys/param.h` in the files where the `OpenBSD` macro is used (when it is not included already). It will also change a couple of instances of the `__OpenBSD__` macro to `OpenBSD`.
See commit 27df23abb675ffeb198bf0c1cc85c4baed77a988 where the usage of `__OpenBSD__` and `OPENBSD` macros were replaced with `OpenBSD`.
See also tickets legacy/trac#6982 and legacy/trac#20980 where the various macros were discussed. The latter ticket is where it was decided to use the `OpenBSD` macro.
I tested on this box:
```
$ uname -mrs
OpenBSD 6.4 amd64
```
Before:
```
=============================================
tor 0.4.0.0-alpha-dev: ./test-suite.log
=============================================
# TOTAL: 20
# PASS: 15
# SKIP: 4
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
<snip>
options/validate__transproxy: [forking]
FAIL src/test/test_options.c:1164: assert(tdata)
[validate__transproxy FAILED]
<snip>
```
...and after:
```
=============================================
tor 0.4.0.0-alpha-dev: ./test-suite.log
=============================================
# TOTAL: 20
# PASS: 16
# SKIP: 4
# XFAIL: 0
# FAIL: 0
# XPASS: 0
# ERROR: 0
```
**Trac**:
**Username**: kjakTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28924Our make V=1 logs have become too verbose for travis2020-06-27T13:51:20ZNick MathewsonOur make V=1 logs have become too verbose for travisFor some reason, Travis thinks that it's unreasonable for us to log this kind of thing for with clang command line:
```
clang -DHAVE_CONFIG_H -I. -I./src -I./src/ext -I./src/ext/trunnel
-I./src/trunnel -I./src/ext -Isrc/ext -DSHARE_D...For some reason, Travis thinks that it's unreasonable for us to log this kind of thing for with clang command line:
```
clang -DHAVE_CONFIG_H -I. -I./src -I./src/ext -I./src/ext/trunnel
-I./src/trunnel -I./src/ext -Isrc/ext -DSHARE_DATADIR="\"/usr/local/share\""
-DLOCALSTATEDIR="\"/usr/local/var\"" -DBINDIR="\"/usr/local/bin\""
-DTOR_UNIT_TESTS -DHAVE_MODULE_DIRAUTH=1 -ftrapv -fsanitize=address
-fsanitize=undefined -g -O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2
-Qunused-arguments -fstack-protector-all -Wstack-protector --param
ssp-buffer-size=1 -fPIE -fno-omit-frame-pointer -fasynchronous-unwind-tables
-Wall -fno-strict-aliasing -Waddress -Waddress-of-array-temporary
-Waddress-of-temporary -Wambiguous-macro -Wanonymous-pack-parens -Warc
-Warc-bridge-casts-disallowed-in-nonarc -Warc-maybe-repeated-use-of-weak
-Warc-performSelector-leaks -Warc-repeated-use-of-weak -Warray-bounds
-Warray-bounds-pointer-arithmetic -Wasm -Wasm-operand-widths
-Watomic-properties -Watomic-property-with-user-defined-accessor -Wauto-import
-Wauto-storage-class -Wauto-var-id -Wavailability -Wbackslash-newline-escape
-Wbind-to-temporary-copy -Wbitfield-constant-conversion -Wbool-conversion
-Wbool-conversions -Wbuiltin-requires-header -Wchar-align
-Wcompare-distinct-pointer-types -Wcomplex-component-init
-Wconditional-type-mismatch -Wconfig-macros -Wconstant-conversion
-Wconstant-logical-operand -Wconstexpr-not-const -Wcustom-atomic-properties
-Wdangling-field -Wdangling-initializer-list -Wdate-time
-Wdelegating-ctor-cycles -Wdeprecated-implementations -Wdeprecated-register
-Wdirect-ivar-access -Wdiscard-qual -Wdistributed-object-modifiers
-Wdivision-by-zero -Wdollar-in-identifier-extension -Wdouble-promotion
-Wduplicate-decl-specifier -Wduplicate-enum -Wduplicate-method-arg
-Wduplicate-method-match -Wdynamic-class-memaccess -Wembedded-directive
-Wempty-translation-unit -Wenum-conversion -Wexit-time-destructors
-Wexplicit-ownership-type -Wextern-initializer -Wextra -Wextra-semi
-Wextra-tokens -Wflexible-array-extensions -Wfloat-conversion -Wformat-non-iso
-Wfour-char-constants -Wgcc-compat -Wglobal-constructors
-Wgnu-array-member-paren-init -Wgnu-designator -Wgnu-static-float-init
-Wheader-guard -Wheader-hygiene -Widiomatic-parentheses -Wignored-attributes
-Wimplicit-atomic-properties -Wimplicit-conversion-floating-point-to-bool
-Wimplicit-exception-spec-mismatch -Wimplicit-fallthrough
-Wimplicit-fallthrough-per-function -Wimplicit-retain-self
-Wimport-preprocessor-directive-pedantic -Wincompatible-library-redeclaration
-Wincompatible-pointer-types-discards-qualifiers -Wincomplete-implementation
-Wincomplete-module -Wincomplete-umbrella -Winit-self -Wint-conversions
-Wint-to-void-pointer-cast -Winteger-overflow -Winvalid-constexpr
-Winvalid-iboutlet -Winvalid-noreturn -Winvalid-pp-token
-Winvalid-source-encoding -Winvalid-token-paste -Wknr-promoted-parameter
-Wlarge-by-value-copy -Wliteral-conversion -Wliteral-range
-Wlocal-type-template-args -Wloop-analysis -Wmain-return-type
-Wmalformed-warning-check -Wmethod-signatures -Wmicrosoft -Wmicrosoft-exists
-Wmismatched-parameter-types -Wmismatched-return-types
-Wmissing-field-initializers -Wmissing-format-attribute -Wmissing-noreturn
-Wmissing-selector-name -Wmissing-sysroot -Wmissing-variable-declarations
-Wmodule-conflict -Wnested-anon-types -Wnewline-eof
-Wnon-literal-null-conversion -Wnon-pod-varargs -Wnonportable-cfstrings
-Wnull-arithmetic -Wnull-character -Wnull-conversion -Wnull-dereference
-Wout-of-line-declaration -Wover-aligned -Woverlength-strings
-Woverriding-method-mismatch -Wpointer-type-mismatch
-Wpredefined-identifier-outside-function
-Wprotocol-property-synthesis-ambiguity -Wreadonly-iboutlet-property
-Wreceiver-expr -Wreceiver-forward-class -Wreinterpret-base-class
-Wrequires-super-attribute -Wreserved-user-defined-literal
-Wreturn-stack-address -Wsection -Wselector-type-mismatch -Wsentinel
-Wserialized-diagnostics -Wshadow -Wshift-count-negative
-Wshift-count-overflow -Wshift-negative-value -Wshift-sign-overflow
-Wshorten-64-to-32 -Wsizeof-array-argument -Wsource-uses-openmp
-Wstatic-float-init -Wstatic-in-inline -Wstatic-local-in-inline
-Wstrict-overflow=1 -Wstring-compare -Wstring-conversion
-Wstrlcpy-strlcat-size -Wstrncat-size -Wsuper-class-method-mismatch
-Wswitch-bool -Wtautological-constant-out-of-range-compare
-Wtentative-definition-incomplete-type -Wtype-safety -Wtypedef-redefinition
-Wtypename-missing -Wundefined-inline -Wundefined-internal
-Wundefined-reinterpret-cast -Wunicode -Wunicode-whitespace
-Wunknown-warning-option -Wunnamed-type-template-args
-Wunneeded-member-function -Wunsequenced -Wunsupported-visibility
-Wunused-command-line-argument -Wunused-exception-parameter
-Wunused-local-typedefs -Wunused-member-function -Wunused-volatile-lvalue
-Wuser-defined-literals -Wvariadic-macros -Wvector-conversion
-Wvector-conversions -Wvexing-parse -Wvisibility -Wvla-extension
-Wzero-length-array -W -Wfloat-equal -Wundef -Wpointer-arith
-Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -Wredundant-decls
-Wchar-subscripts -Wcomment -Wformat=2 -Wwrite-strings -Wnested-externs
-Wbad-function-cast -Wswitch-enum -Waggregate-return -Wpacked -Wunused
-Wunused-parameter -Wold-style-definition -Wmissing-declarations -Werror -MT
src/core/or/src_core_libtor_app_testing_a-onion.o -MD -MP -MF
src/core/or/.deps/src_core_libtor_app_testing_a-onion.Tpo -c -o
src/core/or/src_core_libtor_app_testing_a-onion.o `test -f
'src/core/or/onion.c' || echo './'`src/core/or/onion.c
```
With legacy/trac#27167, it has meant that travis is no longer willing to do do a full verbose clang build.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28895"Your guard" log messages are causing confusion2020-06-27T13:51:21ZGeorge Kadianakis"Your guard" log messages are causing confusionSee this thread https://lists.torproject.org/pipermail/tor-talk/2018-December/044756.html for some confusion that is called by the pathbias log messages refering to guards.
We should improve them since they tend to confuse and agitate u...See this thread https://lists.torproject.org/pipermail/tor-talk/2018-December/044756.html for some confusion that is called by the pathbias log messages refering to guards.
We should improve them since they tend to confuse and agitate users.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28883If many log messages are sent, test_rebind.py does not wait for 60 seconds2020-06-27T13:51:22ZNick MathewsonIf many log messages are sent, test_rebind.py does not wait for 60 secondsThe test_rebind.py script does not wait a full 60 seconds if it receives 600 log messages. This is probably not intended, right?The test_rebind.py script does not wait a full 60 seconds if it receives 600 log messages. This is probably not intended, right?Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28881Initialize addr in parse_port_config2020-06-27T13:51:22ZNick MathewsonInitialize addr in parse_port_configScan-build can't convince itself that the "addr" variable in parse_port_config() is always initialized before use.Scan-build can't convince itself that the "addr" variable in parse_port_config() is always initialized before use.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28879send_resolved_hostname_cell(): Assert first, strlen after.2020-06-27T13:51:22ZNick Mathewsonsend_resolved_hostname_cell(): Assert first, strlen after.Found with scan-build.Found with scan-build.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28851Do we really need to check our hardwired DH primes at startup?2020-06-27T13:51:23ZNick MathewsonDo we really need to check our hardwired DH primes at startup?After the legacy/trac#28837, legacy/trac#28838, and legacy/trac#28839, I note that we're now spending about 24% of our of our startup time in crypto_validate_dh_params().
Since our diffie hellman parameters are hardcoded, maybe we don't...After the legacy/trac#28837, legacy/trac#28838, and legacy/trac#28839, I note that we're now spending about 24% of our of our startup time in crypto_validate_dh_params().
Since our diffie hellman parameters are hardcoded, maybe we don't actually need to validate them on every startup, especially on clients?Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28838Make curve25519_basepoint_spot_check() faster2020-06-27T13:51:24ZNick MathewsonMake curve25519_basepoint_spot_check() fasterThis function is currently around 9% of our startup time, and it does a bunch of curve25519 operations. We could make it a bunch faster, since our curve25519_basepoint function has not been observed to fail in the wild.This function is currently around 9% of our startup time, and it does a bunch of curve25519 operations. We could make it a bunch faster, since our curve25519_basepoint function has not been observed to fail in the wild.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28826Explain appveyor image names2020-06-27T13:51:24ZteorExplain appveyor image namesAppveyor images are called "Visual Studio 2015", but we only care about the Windows versions. (We use MinGW to build tor.)Appveyor images are called "Visual Studio 2015", but we only care about the Windows versions. (We use MinGW to build tor.)Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28698When circuit times are fixed, they can't be "relaxed"2020-06-27T13:51:29ZteorWhen circuit times are fixed, they can't be "relaxed"In legacy/trac#28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that t...In legacy/trac#28639, we had trouble diagnosing a sbws bug. tor said that circuit times were "relaxed", even when LearnCircuitBuildTimeout was 0.
When circuit_build_times_disabled() is true, we should change these log messages so that they make sense:
https://github.com/torproject/tor/blob/b058f64cc002b44e6dd48616ca3163a01c3f3e14/src/core/or/circuituse.c#L591
I think relaxed_timeout is meaningless when circuit_build_times_disabled() is true, but that's another issue.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28669Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc2021-06-23T17:26:02ZtraumschuleBug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_descAfter suspend tor 0.4.0.0-alpha-dev-20181118T011041Z-1~d99.buster+1 had this issue:
```
Nov 26 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
Nov 26 10:37:43.000 [notice] {GENERAL} Your system clock just jumped 35475 s...After suspend tor 0.4.0.0-alpha-dev-20181118T011041Z-1~d99.buster+1 had this issue:
```
Nov 26 00:00:07.000 [notice] Tor 0.4.0.0-alpha-dev opening new log file.
Nov 26 10:37:43.000 [notice] {GENERAL} Your system clock just jumped 35475 seconds forward; assuming established circuits no longer work.
Nov 26 10:38:38.000 [warn] {CIRC} Failed to find node for hop #1 of our path. Discarding this circuit.
Nov 26 10:38:39.000 [notice] {CIRC} Our circuit 0 (id: 202) died due to an invalid selected path, purpose Hidden service client: Fetching HS descriptor. This may be a torrc configuration issue, or a bug.
Nov 26 10:41:00.000 [warn] {BUG} tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(log_backtrace_impl+0x5e) [0x6d4c4e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x6d042d] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(hs_client_dir_info_changed+0xce) [0x5da00e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(router_dir_info_changed+0x34) [0x5ffbc4] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(networkstatus_set_current_consensus+0x41f) [0x5f7fef] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(connection_dir_reached_eof+0xf7f) [0x5c006f] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(connection_handle_read+0x829) [0x53c679] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(+0x568f9) [0x5428f9] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(+0x2091b) [0xb7e3291b] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(event_base_loop+0x4d1) [0xb7e333b1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x672ab0] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(do_main_loop+0xc0) [0x543d40] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_run_main+0x141a) [0x530f9a] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(tor_main+0x3f) [0x52e35f] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(main+0x32) [0x52ded2] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb774c9a1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:01.000 [warn] {BUG} Bug: /usr/bin/tor(+0x41f2e) [0x52df2e] (on Tor 0.4.0.0-alpha-dev )
<repeated once>
Nov 26 10:41:11.000 [notice] {APP} Tried for 120 seconds to get a connection to 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd:993. Giving up. (waiting for rendezvous desc)
Nov 26 10:41:36.000 [warn] {BUG} tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:280: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in retry_all_socks_conn_waiting_for_desc at ../src/feature/hs/hs_client.c:280. Stack trace: (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(log_backtrace_impl+0x5e) [0x6d4c4e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x6d042d] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(hs_client_dir_info_changed+0xce) [0x5da00e] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(router_dir_info_changed+0x34) [0x5ffbc4] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(microdescs_add_list_to_cache+0x2bc) [0x5f1fec] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(microdescs_add_to_cache+0x2ce) [0x5f23ce] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(connection_dir_reached_eof+0x1666) [0x5c0756] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(connection_handle_read+0x829) [0x53c679] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(+0x568f9) [0x5428f9] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(+0x2091b) [0xb7e3291b] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(event_base_loop+0x4d1) [0xb7e333b1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x672ab0] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(do_main_loop+0xc0) [0x543d40] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_run_main+0x141a) [0x530f9a] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(tor_main+0x3f) [0x52e35f] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(main+0x32) [0x52ded2] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb774c9a1] (on Tor 0.4.0.0-alpha-dev )
Nov 26 10:41:36.000 [warn] {BUG} Bug: /usr/bin/tor(+0x41f2e) [0x52df2e] (on Tor 0.4.0.0-alpha-dev )
<repeated once>
Nov 26 10:42:38.000 [notice] {APP} Tried for 120 seconds to get a connection to jukrlvyhgguiedqswc5lehrag2fjunfktouuhi4wozxhb6heyzvshuyd:5222. Giving up. (waiting for rendezvous desc)
```
- jukrlvyhgguiedqswc5lehrag2fjunfktouuhi4wozxhb6heyzvshuyd is Riseup's XMPP server
- 5gdvpfoh6kb2iqbizb37lzk2ddzrwa47m6rpdueg2m656fovmbhoptqd is Riseup's mail server
Didn't have the chance to reproduce it yet.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28668If a Tor unit test causes a BUG log, it should fail2021-09-16T14:27:19ZteorIf a Tor unit test causes a BUG log, it should failIn legacy/trac#28660, a successful unit test logged a BUG warning, but the test still succeeded.
We should make tests fail by default if they log a BUG() or LD_BUG warning, but allow some tests to expect bug warnings.
I thought we made...In legacy/trac#28660, a successful unit test logged a BUG warning, but the test still succeeded.
We should make tests fail by default if they log a BUG() or LD_BUG warning, but allow some tests to expect bug warnings.
I thought we made this change, or had a ticket for this change, but I couldn't find it.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28660rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_all...2020-06-27T13:51:30Zrl1987rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_allocation (On Windows build)https://ci.appveyor.com/project/rl1987/tor/builds/20640384/job/3lk0nnv48m6vc5ni
```
rend_cache/clean: [forking] Nov 29 09:44:28.993 [warn] rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_allocation (on Tor 0.4....https://ci.appveyor.com/project/rl1987/tor/builds/20640384/job/3lk0nnv48m6vc5ni
```
rend_cache/clean: [forking] Nov 29 09:44:28.993 [warn] rend_cache_decrement_allocation(): Bug: Underflow in rend_cache_decrement_allocation (on Tor 0.4.0.0-alpha-dev 9c90bddc42467396)
OK
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/28656Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non...2020-06-27T13:51:30ZmeejahBug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available : Non-fatal assertion !(f_exit > 0.0) failed.I've been running Tor master recently, and saw this. This tor client (should have been) mostly idle for the past several days. It would have been used to create a bunch of custom circuits and then left alone. I see this in the logs:
```...I've been running Tor master recently, and saw this. This tor client (should have been) mostly idle for the past several days. It would have been used to create a bunch of custom circuits and then left alone. I see this in the logs:
```
Nov 28 15:15:31.000 [warn] tor_bug_occurred_(): Bug: src/feature/nodelist/nodelist.c:2501: compute_frac_paths_available: Non-fatal assertion !(f_exit > 0.0) failed. (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: Non-fatal assertion !(f_exit > 0.0) failed in compute_frac_paths_available at src/feature/nodelist/nodelist.c:2501. Stack trace: (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(log_backtrace_impl+0x47) [0x55c0f4988067] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(tor_bug_occurred_+0xc0) [0x55c0f4983630] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(+0x11ca02) [0x55c0f48baa02] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(router_have_minimum_dir_info+0x13f) [0x55c0f48bf3bf] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(directory_info_has_arrived+0x39) [0x55c0f4807469] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(connection_dir_reached_eof+0x103a) [0x55c0f487ff0a] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(connection_handle_read+0x841) [0x55c0f48010e1] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(+0x68fde) [0x55c0f4806fde] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7fdcfe4455a0] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(do_main_loop+0x9d) [0x55c0f48083ad] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(tor_run_main+0x13b3) [0x55c0f47f5ae3] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(tor_main+0x3a) [0x55c0f47f2f1a] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(main+0x19) [0x55c0f47f2a99] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7fdcfd3712e1] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 15:15:31.000 [warn] Bug: ./src/app/tor(_start+0x2a) [0x55c0f47f2aea] (on Tor 0.4.0.0-alpha-dev 469f47ef8dc8b181)
Nov 28 16:22:17.000 [notice] Heartbeat: Tor's uptime is 7 days 0:00 hours, with 0 circuits open. I've sent 2.66 MB and received 25.15 MB.
```
On the advice of `#tor-dev` I'm attaching the datadir.Tor: 0.3.5.x-final