Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T15:51:55Zhttps://gitlab.torproject.org/legacy/trac/-/issues/33491tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal...2020-06-13T15:51:55ZTractor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC ...Hi there,
Receiving the below report, searched for 'src/core/or/dos.c:697' no hits, so opening ticket, please let me know if further info is needed to troubleshoot.
FreeBSD <<hostname>> 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64
```
Mar 1 13:53:33 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:53:33 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: tor_bug_occurred_: Bug: src/core/or/dos.c:697: dos_new_client_conn: Non-fatal assertion !(entry == NULL) failed. (Future instances of this warning will be silenced.) (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: Tor 0.4.2.6: Non-fatal assertion !(entry == NULL) failed in dos_new_client_conn at src/core/or/dos.c:697. Stack trace: (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f4acc <log_backtrace_impl+0x5c> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x12f0b76 <tor_bug_occurred_+0x1d6> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d9a5 <channel_do_open_actions+0xf5> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x118d88e <channel_change_state_open+0x2e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1191a57 <channel_tls_handle_state_change_on_orconn+0x67> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1144946 <connection_or_set_state_open+0x26> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11923ee <channel_tls_handle_cell+0x88e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x1140d52 <connection_or_process_inbuf+0x152> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x114ddad <connection_handle_read+0x8fd> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x119e3ee <connection_add_impl+0x23e> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d72b3 <event_base_assert_ok_nolock_+0xc23> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x8013d318f <event_base_loop+0x53f> at /usr/local/lib/libevent-2.1.so.7 (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x11a0881 <do_main_loop+0xf1> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113de68 <tor_run_main+0x128> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c656 <tor_main+0x66> at /usr/local/bin/tor (on Tor 0.4.2.6 )
Mar 1 13:54:37 <<hostname>> Tor[86742]: Bug: 0x113c309 <main+0x19> at /usr/local/bin/tor (on Tor 0.4.2.6 )
```
**Trac**:
**Username**: sjcjonkerTor: 0.3.5.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/33437Unsuccessful compilation of tor on FreeBSD system with libssl.so.112020-06-13T15:51:48ZTracUnsuccessful compilation of tor on FreeBSD system with libssl.so.11+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files a...+Sebastian | so, this looks like a configure error in detecting available openssl correctly. Please file a bug
----
I'm running into a compilation error related to openssl while compiling tor-0.4.2.6 on FreeBSD 11.3 (amd64). Log files are attached.
Notes:
- compilation of **0.4.2.6** with **libssl.so.9** was successful
- compilation of **0.4.2.6** with **libssl.so.11** was unsuccessful
----
**Trac**:
**Username**: stillicideTor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/28518Complain if net.inet.ip.random_id is not set on FreeBSD-based servers2020-06-13T15:34:21ZfkComplain if net.inet.ip.random_id is not set on FreeBSD-based serversThe attached patch lest Tor complain if net.inet.ip.random_id
is not set on FreeBSD-based servers
Apparently a couple of operators haven't gotten the memos [0] yet
and it looks like FreeBSD's default value will not change any time
s...The attached patch lest Tor complain if net.inet.ip.random_id
is not set on FreeBSD-based servers
Apparently a couple of operators haven't gotten the memos [0] yet
and it looks like FreeBSD's default value will not change any time
soon [1].
[0]:
https://lists.torproject.org/pipermail/tor-relays/2014-March/004199.html
https://lists.torproject.org/pipermail/tor-relays/2014-November/005687.html
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=195828
[1]:
https://lists.freebsd.org/pipermail/freebsd-net/2015-April/041942.htmlTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18448transproxy enabled on FreeBSD but not derivatives2020-06-13T14:54:52ZTractransproxy enabled on FreeBSD but not derivatives```
Hi,
Noticed while investigating #18447, the transproxy feature is only
enabled when __FreeBSD__ is defined, but only regular FreeBSD does that.
Please change this to __FreeBSD_kernel__ which is defined on derivatives
as well.
This...```
Hi,
Noticed while investigating #18447, the transproxy feature is only
enabled when __FreeBSD__ is defined, but only regular FreeBSD does that.
Please change this to __FreeBSD_kernel__ which is defined on derivatives
as well.
This enables the relevant options/validate__transproxy test on FreeBSD
derivatives. (Tested on GNU/kFreeBSD).
Thanks.
```
**Trac**:
**Username**: stevenc99Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/18447Possible double-free in test_options.c2020-06-13T14:54:52ZTracPossible double-free in test_options.c```
Hi,
On derivatives of FreeBSD that have net/pfvar.h, (GNU/kFreeBSD in my
case, but there will be others), USE_TRANSPARENT gets defined but
__FreeBSD__ is not. Therefore when running options/validate__transproxy
in src/test/test_opt...```
Hi,
On derivatives of FreeBSD that have net/pfvar.h, (GNU/kFreeBSD in my
case, but there will be others), USE_TRANSPARENT gets defined but
__FreeBSD__ is not. Therefore when running options/validate__transproxy
in src/test/test_options.c:
1080 free_options_test_data(tdata);
tdata remains a dangling pointer. It may be assigned a new value in one
of the following ifdef blocks, which exist for linux, __FreeBSD__,
DARWIN and __OpenBSD__. So in any other case when we reach:
1115 free_options_test_data(tdata);
it would double-free the tdata from earlier. I've attached a simple
patch to NULL that pointer the first time it is freed.
I will follow up with another ticket to enable transproxy on
GNU/kFreeBSD and enable this test to run on it. Thanks.
Backtrace of the crash with -DNO_FORKING:
#0 routerset_free (routerset=0x21) at src/or/routerset.c:411
cp_sl_idx = <optimized out>
cp_sl_len = <optimized out>
cp = <optimized out>
#1 0x000000000061d4e0 in or_options_free (options=0xae1ad0) at src/or/config.c:800
No locals.
#2 0x000000000051f3e5 in free_options_test_data (td=0xae2750) at src/test/test_options.c:391
No locals.
#3 0x00000000005231f3 in test_options_validate__transproxy (ignored=<optimized out>) at src/test/test_options.c:1115
ret = <optimized out>
tdata = 0xae2750
#4 0x00000000005ede8a in testcase_run_bare_ (testcase=0xaab430 <options_tests+400>) at src/ext/tinytest.c:106
env = 0x0
outcome = <optimized out>
#5 testcase_run_one (group=0xaa61e0 <testgroups+512>, testcase=0xaab430 <options_tests+400>) at src/ext/tinytest.c:253
testcase = 0xaab430 <options_tests+400>
group = 0xaa61e0 <testgroups+512>
#6 0x00000000005ee51e in tinytest_main (c=c@entry=3, v=v@entry=0x7fffffffe5b8, groups=0xaa5fe0 <testgroups>) at src/ext/tinytest.c:435
i = 32
j = 10
n = <optimized out>
#7 0x000000000040d04b in main (c=3, v=0x7fffffffe5b8) at src/test/testing_common.c:300
```
**Trac**:
**Username**: stevenc99Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/3168Vidalia 0.3.0: "Start Tor" button without effect2020-06-13T00:15:35ZfkVidalia 0.3.0: "Start Tor" button without effectAs already reported on or-talk, I'm unable to get Vidalia 0.3.0
to connect to the ControlPort of an already running Tor process.
With Vidalia 0.2.12 it works:
fk@r500 ~ $/usr/obj/usr/ports/net-mgmt/vidalia/work/vidalia-0.2.12/src/vidal...As already reported on or-talk, I'm unable to get Vidalia 0.3.0
to connect to the ControlPort of an already running Tor process.
With Vidalia 0.2.12 it works:
fk@r500 ~ $/usr/obj/usr/ports/net-mgmt/vidalia/work/vidalia-0.2.12/src/vidalia/vidalia --loglevel debug
May 13 14:23:04.497 [notice] Resetting UI translation to English default.
May 13 14:23:04.498 [info] Removing all currently installed UI translator objects.
May 13 14:23:04.647 [notice] Vidalia 0.2.12 using Qt 4.7.2
May 13 14:23:04.724 [notice] QtWarningMsg: Application asked to unregister timer 0x9000004 which is not registered in this thread. Fix application.
May 13 14:23:04.839 [info] Using Tor's GeoIP database for country-level relay mapping.
May 13 14:23:05.008 [notice] Tor status changed from 'Unset' to 'Stopped'.
May 13 14:23:06.980 [notice] Tor status changed from 'Stopped' to 'Starting'.
May 13 14:23:07.020 [notice] Tor status changed from 'Starting' to 'Started'.
May 13 14:23:07.022 [debug] QtDebugMsg: torcontrol: Control connection status changed from 'Unset' to 'Connecting'
May 13 14:23:07.023 [debug] QtDebugMsg: torcontrol: Connecting to Tor (Attempt 1 of 5)
May 13 14:23:07.025 [debug] QtDebugMsg: torcontrol: Starting control connection event loop.
May 13 14:23:07.026 [debug] QtDebugMsg: torcontrol: Control connection status changed from 'Connecting' to 'Connected'
May 13 14:23:07.030 [notice] Tor status changed from 'Started' to 'Authenticating'.
May 13 14:23:07.035 [debug] QtDebugMsg: torcontrol: Control Command: PROTOCOLINFO 1
May 13 14:23:07.037 [debug] QtDebugMsg: torcontrol: Control Reply: 250 PROTOCOLINFO 1
250 AUTH METHODS=NULL
250 VERSION Tor="0.2.3.1-alpha"
250 OK
[...]
With 0.3.0 it doesn't work. Vidalia starts with the
progress bar already at 18%, even though it's not
supposed to connect automatically and the "Start Tor"
button doesn't seem to do anything:
fk@r500 ~ $/usr/obj/usr/ports/net-mgmt/vidalia-devel/work/vidalia-0.3.0/src/vidalia/vidalia --loglevel debug
May 13 12:54:21.401 [notice] Resetting UI translation to English default.
May 13 12:54:21.402 [info] Removing all currently installed UI translator objects.
May 13 12:54:21.517 [notice] Vidalia 0.3.0 using Qt 4.7.2
May 13 12:54:21.670 [info] Using Tor's GeoIP database for country-level relay mapping.
May 13 12:54:21.698 [notice] QtWarningMsg: QSystemTrayIcon::setVisible: No Icon set
May 13 12:54:21.704 [notice] QtWarningMsg: Application asked to unregister timer 0x3600000b which is not registered in this thread. Fix application.
^CMay 13 12:55:30.490 [notice] Cleaning up before exiting.
May 13 12:55:30.496 [notice] Vidalia is exiting cleanly (return code 0).
The behaviour seems to be the same when trying to use
a Control Socket instead of a Control Port.
I'm using FreeBSD 9.0-CURRENT amd64. Tor is running jailed
Vidalia isn't. I don't think it matters here, though.
I'm not using a "SystemTray" application which Vidalia used
to require several years ago (otherwise one wouldn't be able
to start a Window), but not lately.
Given the "QtWarningMsg: QSystemTrayIcon::setVisible" message
that's only in the 0.3.0 output I'm mentioning it anyway.
I'll try to see if installing a "SystemTray" application
makes a difference.Vidalia: 0.3.xTomas ToucedaTomas Toucedahttps://gitlab.torproject.org/legacy/trac/-/issues/7813arm doesn't consistently list connections on OpenBSD 5.12020-06-13T01:52:32ZTracarm doesn't consistently list connections on OpenBSD 5.1using 1.4.5.0 tarball will sometimes work, but it eventually hangs.
using 26ea3b0e690bbbfaf992be19829ac2fa65fc0cc7, but it hangs before drawing anything. the log seems to indicate that it hangs while calling lsof.
going with the theme ...using 1.4.5.0 tarball will sometimes work, but it eventually hangs.
using 26ea3b0e690bbbfaf992be19829ac2fa65fc0cc7, but it hangs before drawing anything. the log seems to indicate that it hangs while calling lsof.
going with the theme of calling external programs for information, i think an appropriate solution is to use the fstat(1) program instead of lsof(1), which is available in the base distribution of OpenBSD, FreeBSD, and NetBSD.
**Trac**:
**Username**: mischiefDamian JohnsonDamian Johnson