Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T13:51:58Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27963Undefined symbol: "timeradd", first referenced in src/lib/libtor-thread.a2020-06-27T13:51:58ZTracUndefined symbol: "timeradd", first referenced in src/lib/libtor-thread.aWhen compiling tor-0.3.5.2-alpha on Solaris10, x64, with gcc 5.2.0 I'm getting an undefined symbole "timeradd", see below (or attached log file):
...
...
CC src/feature/dirauth/src_core_libtor_app_testing_a-shared_random_state.o
...When compiling tor-0.3.5.2-alpha on Solaris10, x64, with gcc 5.2.0 I'm getting an undefined symbole "timeradd", see below (or attached log file):
...
...
CC src/feature/dirauth/src_core_libtor_app_testing_a-shared_random_state.o
AR src/core/libtor-app-testing.a
CC src/tools/tor_runner.o
AR src/tools/libtorrunner.a
CC src/app/main/tor_main.o
CCLD src/app/tor
Undefined first referenced
symbol in file
timeradd src/lib/libtor-thread.a(compat_pthreads.o)
ld: fatal: symbol referencing errors. No output written to src/app/tor
gmake[1]: *** [src/app/tor] Error 1
gmake[1]: Leaving directory `/usr/local/lib/tor-0.3.5.2-alpha'
gmake: *** [all] Error 2
#
**Trac**:
**Username**: KnutTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27962Newline missing between between hs_client_get_random_intro_from_edge() and hs...2020-06-27T13:51:58ZNeel Chauhanneel@neelc.orgNewline missing between between hs_client_get_random_intro_from_edge() and hs_client_receive_introduce_ack()In `feature/hs/hs_client.c` on between lines 1733 and 1734, a newline is missing.In `feature/hs/hs_client.c` on between lines 1733 and 1734, a newline is missing.Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27948Backtrace does not work on NetBSD2020-06-27T13:51:59ZTracBacktrace does not work on NetBSDI've run the self-tests on NetBSD-8.99.25/amd64, and I see two issues:
# TOTAL: 19
# PASS: 12
# SKIP: 5
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
... ...I've run the self-tests on NetBSD-8.99.25/amd64, and I see two issues:
# TOTAL: 19
# PASS: 12
# SKIP: 5
# XFAIL: 0
# FAIL: 2
# XPASS: 0
# ERROR: 0
...
FAIL: src/test/test
===================
....
util/thread/conditionvar_timeout: [forking]
FAIL src/test/test_threads.c:285: assert(ti->n_timeouts OP_EQ 2): 1 vs 2Sep 10 14:30:54.789 [err] Error 16 destroying a mutex.
Sep 10 14:30:54.789 [err] tor_assertion_failed_(): Bug: src/common/compat_pthreads.c:172: tor_mutex_uninit: Assertion 0 failed; aborting. (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: Assertion 0 failed in tor_mutex_uninit at src/common/compat_pthreads.c:172. Stack trace: (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe62985 <log_backtrace+0x4e> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe7d021 <tor_assertion_failed_+0xa0> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe80e3d <tor_mutex_uninit+0xa6> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe693ff <tor_mutex_free_+0x2e> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefc92ee2 <test_threads_conditionvar+0xefa001f3> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefcedd21 <testcase_run_bare_+0xefa00051> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefcedecd <testcase_run_one+0x158> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefcee51c <tinytest_main+0x107> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
Sep 10 14:30:54.793 [err] Bug: 0xefe99621 <main+0x2d1> at ./src/test/test (on Tor 0.3.4.8 da95b91355248ad8)
[Lost connection!]
[conditionvar_timeout FAILED]
util/handle/basic: OK
...
FAIL: src/test/test_bt.sh
=========================
OK
[1] Abort trap "${builddir:-.}/src/test/test-bt-cl" assert 2>&1 |
Done "${PYTHON:-python}" "${abs_top_srcdir:-.}/src/...
BAD
============================================================ T= 1536589911
Tor died: Caught signal 11
0x94a0aa3d <crash_handler+0x94a00043> at ./src/test/test-bt-cl
0x94a0a8cd <crash+0x45> at ./src/test/test-bt-cl
[1] Abort trap "${builddir:-.}/src/test/test-bt-cl" crash 2>&1 |
Done(1) "${PYTHON:-python}" "${abs_top_srcdir:-.}/src/...
-158318
FAIL src/test/test_bt.sh (exit status: 1)
# gdb src/test/test test.core
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from src/test/test...done.
[New process 1]
[New process 5]
[New process 2]
bCore was generated by `test'.
Program terminated with signal SIGABRT, Aborted.
#0 0x00007500d531eeca in _lwp_kill () from /usr/lib/libc.so.12
[Current thread is 1 (process 1)]
(gdb) bt
#0 0x00007500d531eeca in _lwp_kill () from /usr/lib/libc.so.12
#1 0x00007500d531eb57 in abort () at /usr/src/lib/libc/stdlib/abort.c:74
legacy/trac#2 0x00000000efe80e42 in tor_mutex_uninit (m=m@entry=0x7500d3e0b080) at src/common/compat_pthreads.c:172
legacy/trac#3 0x00000000efe693ff in tor_mutex_free_ (m=0x7500d3e0b080) at src/common/compat_threads.c:55
legacy/trac#4 0x00000000efc92ee2 in cv_testinfo_free (i=0x7500d3e09080) at src/test/test_threads.c:186
legacy/trac#5 test_threads_conditionvar (arg=<optimized out>) at src/test/test_threads.c:290
legacy/trac#6 0x00000000efcedd21 in testcase_run_bare_ (testcase=testcase@entry=0xf0263850 <thread_tests+80>) at src/ext/tinytest.c:106
legacy/trac#7 0x00000000efcedecd in testcase_run_forked_ (group=<optimized out>, testcase=0xf0263850 <thread_tests+80>) at src/ext/tinytest.c:190
legacy/trac#8 testcase_run_one (group=<optimized out>, testcase=0xf0263850 <thread_tests+80>) at src/ext/tinytest.c:248
legacy/trac#9 0x00000000efcee51c in tinytest_main (c=<optimized out>, v=<optimized out>, groups=<optimized out>) at src/ext/tinytest.c:435
legacy/trac#10 0x00000000efe99621 in main (c=1, v=0x7f7fffc611d8) at src/test/testing_common.c:319
**Trac**:
**Username**: wizTor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27943Broken Appveyor build2020-06-27T13:51:59Zrl1987Broken Appveyor build```
checking for file conflicts...
error:
failed to commit transaction (conflicting files)
```
https://ci.appveyor.com/project/torproject/tor/build/1.0.1020/job/o62dw3iklb8da8wv```
checking for file conflicts...
error:
failed to commit transaction (conflicting files)
```
https://ci.appveyor.com/project/torproject/tor/build/1.0.1020/job/o62dw3iklb8da8wvTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27928Refrain from listener rebinding when address families differ2020-06-27T13:51:59Zrl1987Refrain from listener rebinding when address families differIn `retry_listener_ports`, we check if port matches exactly and *one* of the addresses is a wildcard address:
```
2795 const int may_need_rebind =
2796 port_matches_exact && bool_neq(tor_addr_is_null(&wanted->addr),
279...In `retry_listener_ports`, we check if port matches exactly and *one* of the addresses is a wildcard address:
```
2795 const int may_need_rebind =
2796 port_matches_exact && bool_neq(tor_addr_is_null(&wanted->addr),
2797 tor_addr_is_null(&conn->addr));
```
We should also check if address family is the same between old and new listener. If they differ, we don't need to do rebinding. See discussion on legacy/trac#17873.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27924Split up routerparse.c2020-06-27T13:51:59ZNick MathewsonSplit up routerparse.cIt's one of the largest files still in tor, and it should divide up nicely.It's one of the largest files still in tor, and it should divide up nicely.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27913Add test-stem to travis-ci if possible2020-06-27T13:52:00ZNick MathewsonAdd test-stem to travis-ci if possibleTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27900Please establish which C standard tor code complies with2020-06-27T13:52:00Zyurivict271Please establish which C standard tor code complies withCurrently, tor is built without the -std=xx flag, and it isn't clear what C standard is compiler expected to use.
Please add one of -std=c90, -std=c99, -std=c11, -std=c17 to compilation lines, add the corresponding macro to configure.ac...Currently, tor is built without the -std=xx flag, and it isn't clear what C standard is compiler expected to use.
Please add one of -std=c90, -std=c99, -std=c11, -std=c17 to compilation lines, add the corresponding macro to configure.ac:
> AX_CHECK_COMPILE_FLAG([-std=cNN], [CFLAGS="$CFLAGS -std=cNN"])
Reason#1: in FreeBSD we have several architectures some of which use different compilers (gcc/clang/etc) It is good to take guessing from the process and establish what standard the code complies with.
Reason#2: Some compilers might default to the older standard where a newer standard is required.
My guess is that the standard is c11.Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27893memory leak in dump_config()2020-06-27T13:52:01ZNick Mathewsonmemory leak in dump_config()I build with AddressSanitizer and run `./src/app/tor --dump-config non-builtin`. This gives me:
```
Direct leak of 39 byte(s) in 2 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x7fc055a1...I build with AddressSanitizer and run `./src/app/tor --dump-config non-builtin`. This gives me:
```
Direct leak of 39 byte(s) in 2 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x7fc055a14c37 in __GI___vasprintf_chk (/lib64/libc.so.6+0x10ac37)
Direct leak of 17 byte(s) in 1 object(s) allocated from:
#0 0x7fc058855320 in strdup (/lib64/libasan.so.5+0x3b320)
#1 0x55c6f60d7780 in tor_strdup_ src/lib/malloc/malloc.c:165
#2 0x55c6f5f5b327 in validate_data_directories src/app/config/config.c:7856
#3 0x55c6f5f5b327 in options_validate src/app/config/config.c:3385
#4 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#5 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#6 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#7 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#8 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#9 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#10 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Direct leak of 16 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d3115 in smartlist_new src/lib/smartlist_core/smartlist_core.c:28
#3 0x55c6f5f6294c in options_validate_scheduler src/app/config/config.c:3239
#4 0x55c6f5f6294c in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 128 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f60d31c9 in smartlist_new src/lib/smartlist_core/smartlist_core.c:31
#4 0x55c6f5f6294c in options_validate_scheduler src/app/config/config.c:3239
#5 0x55c6f5f6294c in options_validate src/app/config/config.c:4533
#6 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#7 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#8 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#9 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#10 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#11 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#12 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f5f62bc3 in options_validate_scheduler src/app/config/config.c:3243
#4 0x55c6f5f62bc3 in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f5f62a65 in options_validate_scheduler src/app/config/config.c:3251
#4 0x55c6f5f62a65 in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
Indirect leak of 4 byte(s) in 1 object(s) allocated from:
#0 0x7fc058908c48 in malloc (/lib64/libasan.so.5+0xeec48)
#1 0x55c6f60d74da in tor_malloc_ src/lib/malloc/malloc.c:45
#2 0x55c6f60d7571 in tor_malloc_zero_ src/lib/malloc/malloc.c:71
#3 0x55c6f5f63318 in options_validate_scheduler src/app/config/config.c:3247
#4 0x55c6f5f63318 in options_validate src/app/config/config.c:4533
#5 0x55c6f5f6c3d5 in options_validate_cb src/app/config/config.c:3146
#6 0x55c6f5f8df68 in config_dump src/app/config/confparse.c:964
#7 0x55c6f5a43cda in do_dump_config src/app/main/main.c:950
#8 0x55c6f5a43cda in tor_run_main src/app/main/main.c:1502
#9 0x55c6f5a3baab in tor_main src/feature/api/tor_api.c:164
#10 0x55c6f5a361eb in main src/app/main/tor_main.c:32
#11 0x7fc05592d11a in __libc_start_main (/lib64/libc.so.6+0x2311a)
```
I think this is happening because options_validate is called from config_dump(), but config_dump() frees defaults_tmp using config_free instead of or_options_free.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27892Split the non-stats part of the stats module into different modules2021-09-16T14:28:09ZNick MathewsonSplit the non-stats part of the stats module into different modulesPart of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Part of rephist.c is about predicted ports, which aren't really stats.
Part of geoip.c is about stats, but part is about mapping IPs to countries, which isn't stats.
Let's fix this while we can.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27864Split router.c and routerkeys.c into separate modules2021-09-16T14:28:09ZNick MathewsonSplit router.c and routerkeys.c into separate modulesTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27861Tor 0.3.5.2-alpha-dev c82163dff468443d Bug in tor_assertion_failed_()2020-06-27T13:52:02ZTracTor 0.3.5.2-alpha-dev c82163dff468443d Bug in tor_assertion_failed_()Hi
Here is the log:
Sep 25 22:54:55.000 [notice] new bridge descriptor 'ahwahnee' (cached): $193423CE506EB2EE2BC119C40CCC9CA2C0B403BA~ahwahnee at 137.74.197.106
Sep 25 22:54:55.000 [debug] routerlist_retry_directory_downloads(): In rout...Hi
Here is the log:
Sep 25 22:54:55.000 [notice] new bridge descriptor 'ahwahnee' (cached): $193423CE506EB2EE2BC119C40CCC9CA2C0B403BA~ahwahnee at 137.74.197.106
Sep 25 22:54:55.000 [debug] routerlist_retry_directory_downloads(): In routerlist_retry_directory_downloads()
Sep 25 22:54:55.000 [debug] router_reset_descriptor_download_failures(): In router_reset_descriptor_download_failures()
Sep 25 22:54:55.000 [debug] networkstatus_reset_download_failures(): In networkstatus_reset_download_failures()
Sep 25 22:54:55.000 [err] tor_assertion_failed_(): Bug: src/core/mainloop/mainloop.c:1641: reschedule_directory_downloads: Assertion fetch_networkstatus_event failed; aborting. (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: Assertion fetch_networkstatus_event failed in reschedule_directory_downloads at src/core/mainloop/mainloop.c:1641. Stack trace: (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(log_backtrace_impl+0x48) [0x55c5d29aee78] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(tor_assertion_failed_+0x97) [0x55c5d29aa347] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(reschedule_directory_downloads+0x78) [0x55c5d2820728] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(routerlist_descriptors_added+0xc4) [0x55c5d28d8bc4] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(router_load_routers_from_string+0x41a) [0x55c5d28daf5a] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(+0x1213a4) [0x55c5d28db3a4] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(router_reload_router_list+0x26) [0x55c5d28db536] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(tor_run_main+0x1524) [0x55c5d280e594] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(tor_main+0x3b) [0x55c5d280b62b] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(main+0x1a) [0x55c5d280b1ba] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: /usr/lib/libc.so.6(__libc_start_main+0xf3) [0x7f4331b06223] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
Sep 25 22:54:55.000 [err] Bug: tor(_start+0x2e) [0x55c5d280b21e] (on Tor 0.3.5.2-alpha-dev c82163dff468443d)
**Trac**:
**Username**: fo0xyTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27856dh_initialized in crypto_dh_nss.c is always zero2020-06-27T13:52:02ZTracdh_initialized in crypto_dh_nss.c is always zero
**Trac**:
**Username**: cyberpunks
**Trac**:
**Username**: cyberpunksTor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27853tor-resolve manpage points to doc/socks-extensions.txt2020-06-27T13:52:02Zrl1987tor-resolve manpage points to doc/socks-extensions.txt> See doc/socks-extensions.txt in the Tor package for protocol details.
We no longer have a file at this path in tor repo.> See doc/socks-extensions.txt in the Tor package for protocol details.
We no longer have a file at this path in tor repo.Tor: 0.3.5.x-finalrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/27849Bootstrapping hangs with 'SocksPort 0'2020-06-27T13:52:02ZTracBootstrapping hangs with 'SocksPort 0'Debian uses a minimal torrc on onion.debian.org (our onionbalance node) and tor from Debian backports. We recently upgraded from 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 and discovered that our onionbalance services were no longer working, b...Debian uses a minimal torrc on onion.debian.org (our onionbalance node) and tor from Debian backports. We recently upgraded from 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 and discovered that our onionbalance services were no longer working, but the backend onion services and our normal onion services were still working. The issue was that the tor daemon on onion.debian.org could not achieve bootstrap. tor 0.3.3.9 worked with the existing config, but 0.3.4.8 did not. Changing the SocksPort parameter from 0 to 6666 allowed tor 0.3.4.8 to achieve bootstrap.
The config does not contain any onion services, because those are setup by onionbalance via the tor control port.
So the issue appears to be that tor is not trying to contact the tor network unless it has a socks port or an onion service or other tor network requiring thing configured.
```
SocksPort 0
Log notice syslog
#HiddenServiceSingleHopMode 1
#HiddenServiceNonAnonymousMode 1
ControlPort 9051
```
**Trac**:
**Username**: pabsTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27841Surprise race: Intro point closes circuit after NACK, at the same time as cli...2022-10-11T23:39:49ZGeorge KadianakisSurprise race: Intro point closes circuit after NACK, at the same time as client tries to extend circuit to new intro pointWe are currently leaving inroduction circuits open after intro has been done, even tho we ignore any further introductions on that circuit.
In the future, we can consider closing that circuit to decrease the load on the network.We are currently leaving inroduction circuits open after intro has been done, even tho we ignore any further introductions on that circuit.
In the future, we can consider closing that circuit to decrease the load on the network.Tor: 0.3.5.x-finalNeel Chauhanneel@neelc.orgNeel Chauhanneel@neelc.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27838v3 onion service wrongly considers Invalid signature for service descriptor s...2021-09-30T13:25:25Zs7rv3 onion service wrongly considers Invalid signature for service descriptor signing key: expiredI host on a server 2 onion services (one v2 and one v3).
Exact Tor version is: `Tor version 0.3.5.0-alpha-dev`
Suddenly, the v3 onion service went down. This was showing in the log file:
```
Sep 23 14:04:00.000 [notice] Tor has succes...I host on a server 2 onion services (one v2 and one v3).
Exact Tor version is: `Tor version 0.3.5.0-alpha-dev`
Suddenly, the v3 onion service went down. This was showing in the log file:
```
Sep 23 14:04:00.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Sep 23 14:04:02.000 [warn] Invalid signature for service descriptor signing key: expired
Sep 23 14:04:02.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_descriptor.c:2661: hs_desc_encode_descriptor: Non-fatal assertion !(ret < 0) failed. (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: Non-fatal assertion !(ret < 0) failed in hs_desc_encode_descriptor at ../src/feature/hs/hs_descriptor.c:2661. Stack trace: (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x47) [0x55e9e1761257] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55e9e175ca60] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(hs_desc_encode_descriptor+0x106) [0x55e9e1667996] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(hs_service_run_scheduled_events+0x1ab9) [0x55e9e166ff49] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(+0x562e1) [0x55e9e15cd2e1] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(+0x5dc11) [0x55e9e15d4c11] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f246c99f5a0] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x265) [0x55e9e15d11b5] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x11f5) [0x55e9e15d3a35] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x55e9e15cba0a] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x55e9e15cb589] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f246b1fb2e1] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x55e9e15cb5da] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] tor_bug_occurred_(): Bug: ../src/feature/hs/hs_service.c:2816: upload_descriptor_to_hsdir: Non-fatal assertion !(service_encode_descriptor(service, desc, &desc->signing_kp, &encoded_desc) < 0) failed. (on Tor $
Sep 23 14:04:02.000 [warn] Bug: Non-fatal assertion !(service_encode_descriptor(service, desc, &desc->signing_kp, &encoded_desc) < 0) failed in upload_descriptor_to_hsdir at ../src/feature/hs/hs_service.c:2816. Stack trace: (on Tor 0.3.$
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(log_backtrace_impl+0x47) [0x55e9e1761257] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(tor_bug_occurred_+0xc0) [0x55e9e175ca60] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(hs_service_run_scheduled_events+0x1d5b) [0x55e9e16701eb] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(+0x562e1) [0x55e9e15cd2e1] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(+0x5dc11) [0x55e9e15d4c11] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5(event_base_loop+0x6a0) [0x7f246c99f5a0] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(do_main_loop+0x265) [0x55e9e15d11b5] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(tor_run_main+0x11f5) [0x55e9e15d3a35] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(tor_main+0x3a) [0x55e9e15cba0a] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(main+0x19) [0x55e9e15cb589] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0x7f246b1fb2e1] (on Tor 0.3.5.0-alpha-dev )
Sep 23 14:04:02.000 [warn] Bug: /usr/bin/tor(_start+0x2a) [0x55e9e15cb5da] (on Tor 0.3.5.0-alpha-dev )
```
It reported that stack trace over and over for few hours, during the time of some internet connectivity problems. The v3 hidden service was unavailable during all this time of course.
Some additional info:
The internet was not working properly when this happened. The IPv4 bgp session was down and only IPv6 was working on the server. I have checked the Guard this particular Tor instance was using and it had an IPv6 ORPort (maybe this lead to a false positive wrt to testing our own network connection).
The bigger problem is that when everything came back online, the bug stack trace was not printing in the log file any more, but the v3 onion service did not recover by itself and still wasn't accessible. Had to restart the Tor process entirely and it came back online.Tor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/27829Bug: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed in ret...2020-06-27T13:52:03ZtraumschuleBug: 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:279This trace appeared several times in today's log, assumingly the amount corresponds to the number of configured onion services. No relay.
```
Sep 23 00:00:56.000 [notice] Tor 0.3.5.1-alpha-dev opening new log file.
Sep 23 01:27:56.000 [n...This trace appeared several times in today's log, assumingly the amount corresponds to the number of configured onion services. No relay.
```
Sep 23 00:00:56.000 [notice] Tor 0.3.5.1-alpha-dev opening new log file.
Sep 23 01:27:56.000 [notice] {HEARTBEAT} Heartbeat: Tor's uptime is 1 day 23:54 hours, with 37 circuits open. I've sent 121.54 MB and received 1.02 GB.
Sep 23 01:27:56.000 [notice] {HEARTBEAT} Average packaged cell fullness: 58.689%. TLS write overhead: 4%
Sep 23 01:27:56.000 [notice] {HEARTBEAT} Our onion services received 39 v2 and 898 v3 INTRODUCE2 cells and attempted to launch 944 rendezvous circuits.
Sep 23 10:56:54.000 [notice] {GENERAL} Your system clock just jumped 31462 seconds forward; assuming established circuits no longer work.
Sep 23 10:57:23.000 [warn] {BUG} tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:279: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.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:279. Stack trace: (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(log_backtrace_impl+0x5e) [0x665cae] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(tor_bug_occurred_+0xbd) [0x66157d] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(hs_client_dir_info_changed+0xce) [0x55b38e] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(router_dir_info_changed+0x34) [0x57be74] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(networkstatus_set_current_consensus+0x41d) [0x5743dd] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(connection_dir_reached_eof+0xf69) [0x545329] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(connection_handle_read+0x829) [0x5f7999] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(+0x42909) [0x4c4909] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(+0x2091b) [0xb7d8991b] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/lib/i386-linux-gnu/libevent-2.1.so.6(event_base_loop+0x4d1) [0xb7d8a3b1] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(tor_libevent_run_event_loop+0x30) [0x605000] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(do_main_loop+0x228) [0x4c6bb8] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(tor_run_main+0x10d5) [0x4c9375] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(tor_main+0x3f) [0x4c134f] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(main+0x32) [0x4c0ec2] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf1) [0xb77219a1] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:23.000 [warn] {BUG} Bug: /usr/bin/tor(+0x3ef1e) [0x4c0f1e] (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:57:30.000 [notice] {CIRC} Your network connection speed appears to have changed. Resetting timeout to 60s after 18 timeouts and 1000 buildtimes.
Sep 23 10:58:15.000 [warn] {BUG} tor_bug_occurred_(): Bug: ../src/feature/hs/hs_client.c:279: retry_all_socks_conn_waiting_for_desc: Non-fatal assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed. (on Tor 0.3.5.1-alpha-dev )
Sep 23 10:58:15.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:279. Stack trace: (on Tor 0.3.5.1-alpha-dev )
<trace repeated several times>
```Tor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/27826incompatibility between tor 0.3.4.8 and onionbalance 0.1.62020-06-27T13:52:03ZTracincompatibility between tor 0.3.4.8 and onionbalance 0.1.6Debian recently upgraded our onion services from tor 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 (from the Debian stretch-backports archive) while using onionbalance 0.1.6-1 from Debian stretch. This broke all of our onion services that are bac...Debian recently upgraded our onion services from tor 0.3.3.9-1~bpo9+1 to 0.3.4.8-1~bpo9+1 (from the Debian stretch-backports archive) while using onionbalance 0.1.6-1 from Debian stretch. This broke all of our onion services that are backed by multiple hosts using onionbalance. Access to the backend addresses was working fine in Tor Browser, but the frontend addresses were timing out. I tried downgrading tor on the backends but that did not help. Downgrading tor on the onionbalance host helped and upgrading onionbalance to 0.1.8-3 from Debian buster also fixed the issue. I've requested an onionbalance backport but on IRC arma requested I file a bug report about the incompatibility. The onionbalance logs showed lots of these errors:
```
[WARNING]: Error generating descriptor: No introduction points for service <frontend>.onion.
[INFO]: Our descriptor for instance <backend>.onion is too old. The instance may be offline.
```
PS: arma requested on IRC that dgoulet/asn look at this.
**Trac**:
**Username**: pabsTor: 0.3.5.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/278180.3.5.2-alpha undefined reference to `get_uint32' on ARM device.2020-06-27T13:52:04ZTrac0.3.5.2-alpha undefined reference to `get_uint32' on ARM device.I already have tor running well on gl-ar150 router.
Also have another device, a Raspberry Pi configured to run openwrt.
I can do ssh and mount device files remotely to both.
I wish to run tor on the latter Pi device (but the ar-150 repos...I already have tor running well on gl-ar150 router.
Also have another device, a Raspberry Pi configured to run openwrt.
I can do ssh and mount device files remotely to both.
I wish to run tor on the latter Pi device (but the ar-150 repository is device specific and won't work on the Pi). The Pi is a minimal install and won't run the make command but I have another Pi of the same type on which I am trying to compile tor, the binary might work. (Raspbian GNU/Linux" VERSION="7 (wheezy)").
Problem, how to install tor
https://tor.stackexchange.com/questions/75/how-can-i-install-tor-from-the-source-code-in-the-git-repository
---------------
Notes on what I did
sudo apt-get update
sudo apt-get upgrade
sudo apt-get install git build-essential automake libevent-dev libssl-dev
git clone https://git.torproject.org/tor.git
ChangeLog gives version as 0.3.5.2-alpha
chmod +x autogen.sh
sudo ./autogen.sh
sudo make
./configure
sudo apt-get install asciidoc
./configure
make
Error resulted as follows
CC src/tools/tor_runner.o
AR src/tools/libtorrunner.a
CC src/app/main/tor_main.o
CCLD src/app/tor
src/lib/libtor-crypt-ops.a(src_lib_libtor_crypt_ops_a-aes_openssl.o): In function `aes_set_iv':
/home/pi/tor/src/lib/crypt_ops/aes_openssl.c:399: undefined reference to `get_uint32'
/home/pi/tor/src/lib/crypt_ops/aes_openssl.c:400: undefined reference to `get_uint32'
/home/pi/tor/src/lib/crypt_ops/aes_openssl.c:401: undefined reference to `get_uint32'
/home/pi/tor/src/lib/crypt_ops/aes_openssl.c:402: undefined reference to `get_uint32'
collect2: ld returned 1 exit status
Makefile:6918: recipe for target 'src/app/tor' failed
make[1]: *** [src/app/tor] Error 1
make[1]: Leaving directory '/home/pi/tor'
Makefile:4580: recipe for target 'all' failed
make: *** [all] Error 2
I suspect a header reference is missing. I can collect the detailed output if necessary and will try to attach partial terminal output from the compile.
**Trac**:
**Username**: PradaTor: 0.3.5.x-final