Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:33Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/525Non-servers and hibernating servers still relay traffic2020-06-27T14:10:33ZNick MathewsonNon-servers and hibernating servers still relay trafficSee thread on or-dev: "Turning off a server", especially Roger's comments at
http://archives.seul.org/or/dev/Oct-2007/msg00007.html
There are two issues here:
1) Perhaps non-servers (those with ORPort off) should be disabled in the...See thread on or-dev: "Turning off a server", especially Roger's comments at
http://archives.seul.org/or/dev/Oct-2007/msg00007.html
There are two issues here:
1) Perhaps non-servers (those with ORPort off) should be disabled in the same way as hibernating servers.
2) Perhaps active streams should get throttled or killed. once we're hibernating or ORPort is off.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/516read-history/write-history show non-relayed traffic too2020-06-27T14:10:33ZRoger Dingledineread-history/write-history show non-relayed traffic tooIn connection_buckets_decrement(), we report to rep_hist_note_bytes_read/written
whether the traffic was relayed traffic or our own traffic. If the user sets
RelayBandwidthRate and the relayed traffic constantly hits that level, then
any...In connection_buckets_decrement(), we report to rep_hist_note_bytes_read/written
whether the traffic was relayed traffic or our own traffic. If the user sets
RelayBandwidthRate and the relayed traffic constantly hits that level, then
any numbers higher than that in the read-history/write-history lines will be
due to locally initiated traffic.
The easy fix would be to only count bytes that were sent on relayed connections --
so locally initiated directory connections, and all circuits on connections that
recently carried traffic for an origin circuit, would be ignored:
Index: connection.c
===================================================================
--- connection.c (revision 11723)
+++ connection.c (working copy)
@@ -1546,12 +1546,12 @@
if (!connection_is_rate_limited(conn))
return; /* local IPs are free */
- if (num_read > 0)
- rep_hist_note_bytes_read(num_read, now);
- if (num_written > 0)
- rep_hist_note_bytes_written(num_written, now);
+ if (connection_counts_as_relayed_traffic(conn, now)) {
+ if (num_read > 0)
+ rep_hist_note_bytes_read(num_read, now);
+ if (num_written > 0)
+ rep_hist_note_bytes_written(num_written, now);
- if (connection_counts_as_relayed_traffic(conn, now)) {
global_relayed_read_bucket -= num_read;
global_relayed_write_bucket -= num_written;
}
Then I realized that this has the mirror-image problem: if the server
has uniform enough usage around its BandwidthRate, then just as we
were looking at spikes before and knowing they came from non-relayed
traffic, now we look at dips and conclude the same thing.
Hm.
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/515creation of _tor user broken in latest leopard build2020-06-27T14:10:34ZTraccreation of _tor user broken in latest leopard buildThis bug is connected with legacy/trac#443.
The new way of user creation worked with older leopard builds,
but with leopard 10.5 build 9a559 installation of tor fails.
is there a "debug installation mode"? i could provide a log than.
[...This bug is connected with legacy/trac#443.
The new way of user creation worked with older leopard builds,
but with leopard 10.5 build 9a559 installation of tor fails.
is there a "debug installation mode"? i could provide a log than.
[Automatically added by flyspray2trac: Operating System: OSX 10.5 Leopard]
**Trac**:
**Username**: daveAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/512Vidalia Bundle - Vidalia Starts but No Vidalia Tray Icon; Tor Doesn't Start2020-06-27T14:10:34ZTracVidalia Bundle - Vidalia Starts but No Vidalia Tray Icon; Tor Doesn't StartWhen I launch Privoxy (via Startup Group), Privoxy and Vidalia startup; however, Tor does not startup, so I end up having to manually launch Tor, which works fine afterwards. In addition, the Vidalia Control Panel Icon does not appear i...When I launch Privoxy (via Startup Group), Privoxy and Vidalia startup; however, Tor does not startup, so I end up having to manually launch Tor, which works fine afterwards. In addition, the Vidalia Control Panel Icon does not appear in the system tray, so I have no means to configure Vidalia. Any idea what is causing this behavior? Incidentally, I have the same problem using either the standard Vidalia-Tor Packages (Stable and Alpha releases) or PortableTor. Never does the Vidalia Tracy Icon appear or does Tor automatically startup.
Please help.
Thanks!
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Shawnhttps://gitlab.torproject.org/tpo/core/tor/-/issues/508Startup priority too low2020-06-27T14:10:34ZTracStartup priority too lowShort overview, Vidalia Bundle takes ages
to start if all cpu cycles are sucked away.
I am taking part in the Great Internet Mersenne Prime Search (GIMPS)
which a distributed computing project. The program PRIME95.exe is
running at pr...Short overview, Vidalia Bundle takes ages
to start if all cpu cycles are sucked away.
I am taking part in the Great Internet Mersenne Prime Search (GIMPS)
which a distributed computing project. The program PRIME95.exe is
running at priority 1 and is effectivly using my whole idle cycles.
How ever, I've noticed that if you start Vidalia (which kicks Tor up) it will nearly hang
and the interface is not usable until Tor starts its "normal" activity while PRIME95 is running.
I suspect Tor to startup on a very low (0?) prio and therefore it is unable to start if no cpu is left.
After the Tor has checked that everything is ok ("Self-testing indicates your
DirPort is reachable from the outside. Excellent.") it runs smoothly even with PRIME95 present.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: knappohttps://gitlab.torproject.org/tpo/core/tor/-/issues/507tor-gencert linked against event/pthread2021-09-16T14:36:24Zweasel (Peter Palfrader)tor-gencert linked against event/pthreadtor-gencert is linked against libevent and libpthread tho it probably doesn't need those.
Since tor-gencert is quite a file that you might want to transfer to a computer that
doesn't have libevent it would be nice if it could not be link...tor-gencert is linked against libevent and libpthread tho it probably doesn't need those.
Since tor-gencert is quite a file that you might want to transfer to a computer that
doesn't have libevent it would be nice if it could not be linked against that library.
Unless of course it needs libevent.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedrl1987rl1987https://gitlab.torproject.org/tpo/core/tor/-/issues/501DataDirectory setting still leaves a remnant in the default DataDirectory2020-06-27T14:10:34ZTracDataDirectory setting still leaves a remnant in the default DataDirectoryIf Tor is started, even with a DataDirectory specified, a file called "state" is created in a folder named "tor" in the Application Directory. This file should not be created if the DataDirectory is set somewhere else. To replicate the b...If Tor is started, even with a DataDirectory specified, a file called "state" is created in a folder named "tor" in the Application Directory. This file should not be created if the DataDirectory is set somewhere else. To replicate the bug, set a DataDirectory to a location, and check for remnants in the system's Application Data directory.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Silivrenionhttps://gitlab.torproject.org/tpo/core/tor/-/issues/499Win32 - duplicate state file created2020-06-27T14:10:34ZTracWin32 - duplicate state file createdTor v0.1.2.17 under Win32 (maybe others?)
When using the DataDirectory setting in my torrc file (same setting as in Vidalia) a duplicate 'state' file
is created in '%APPDATA%\tor', regardless of the setting. The rest of the files (cach...Tor v0.1.2.17 under Win32 (maybe others?)
When using the DataDirectory setting in my torrc file (same setting as in Vidalia) a duplicate 'state' file
is created in '%APPDATA%\tor', regardless of the setting. The rest of the files (cachedstatus, etc.) are
saved to the specified directory along with another copy of the 'state' file.
Does the Vidalia setting take precedence over the torrc setting anyway?
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: wraithduhttps://gitlab.torproject.org/tpo/core/tor/-/issues/493.exit TLD does not behave transparently2020-06-27T14:10:35ZTrac.exit TLD does not behave transparentlyThe .exit TLD does not work like the ExitNodes config option. Whatever it does, it does not simply ask a particular exit node to cleanly request a particular URL.
For example, http://en.wikipedia.org.bostonucompsci.exit/ returns a very ...The .exit TLD does not work like the ExitNodes config option. Whatever it does, it does not simply ask a particular exit node to cleanly request a particular URL.
For example, http://en.wikipedia.org.bostonucompsci.exit/ returns a very different result than http://en.wikipedia.org/ with a "ExitNodes bostonucompsci" config. I can't say why, but try it. Don't go asking the Wikipedia folks what the difference is; they'll just flip out and start blocking all the newer nodes again.
I chose that exit node because it's running 0.1.2.17, but any node will give the same results, including those running 0.2.0.6-alpha. I'm running 0.1.2.17 on win2k.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: Dodgerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/488Connection problems with Tor2020-06-27T14:10:35ZTracConnection problems with TorAug 31 22:01:45.137 [Notice] Tor v0.1.2.16. This is experimental software. Do not rely on it for strong anonymity.
Aug 31 22:01:45.167 [Notice] Initialized libevent version 1.3b using method win32. Good.
Aug 31 22:01:45.177 [Notice] Open...Aug 31 22:01:45.137 [Notice] Tor v0.1.2.16. This is experimental software. Do not rely on it for strong anonymity.
Aug 31 22:01:45.167 [Notice] Initialized libevent version 1.3b using method win32. Good.
Aug 31 22:01:45.177 [Notice] Opening Socks listener on 127.0.0.1:9050
Aug 31 22:01:45.177 [Notice] Opening Control listener on 127.0.0.1:9051
Aug 31 22:02:35.920 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:03:05.753 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:04:35.171 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:05:05.255 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:06:46.150 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:06:47.021 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:08:05.544 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:08:46.593 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:08:47.594 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:18:08.992 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:18:58.543 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
Aug 31 22:20:58.505 [Notice] Tried for 120 seconds to get a connection to [scrubbed]:80. Giving up. (waiting for circuit)
Aug 31 22:26:40.968 [Notice] Application request when we're believed to be offline. Optimistically trying directory fetches again.
This is from vidalia message log. Before this i had the problem of tor crashing over and over again due to insufficient memory.
Frustrated, i reinstalled the entire vidalia bundle and this error popped out when i tried to use tor. Can you please help me? Thank you.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: watisitAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/484not freeing an mmap2020-06-27T14:10:35ZRoger Dingledinenot freeing an mmap==26396== 12 bytes in 1 blocks are definitely lost in loss record 4 of 10
==26396== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==26396== by 0x80E6C0C: _tor_malloc (util.c:119)
==26396== by 0x80E6C64: _tor_malloc_zero (util.c...==26396== 12 bytes in 1 blocks are definitely lost in loss record 4 of 10
==26396== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==26396== by 0x80E6C0C: _tor_malloc (util.c:119)
==26396== by 0x80E6C64: _tor_malloc_zero (util.c:138)
==26396== by 0x80EDA36: tor_mmap_file (compat.c:172)
==26396== by 0x80C79E2: router_rebuild_store (routerlist.c:591)
==26396== by 0x80C7F88: router_reload_router_list_impl (routerlist.c:694)
==26396== by 0x80C7FCE: router_reload_router_list (routerlist.c:712)
==26396== by 0x80ADAE2: do_main_loop (main.c:1366)
==26396== by 0x80AF05A: tor_main (main.c:2660)
==26396== by 0x80E5C55: main (tor_main.c:28)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/483Mac OS X connection.c:9322020-06-27T14:10:35ZTracMac OS X connection.c:932Here's the error from the log file.
I've only seen it once.
Aug 19 11:14:30.640 [Error] Bug: connection.c:932: connection_handle_listener_read: Assertion ((struct sockaddr*)addrbuf)->sa_family == conn->socket_family failed; aborting.
I...Here's the error from the log file.
I've only seen it once.
Aug 19 11:14:30.640 [Error] Bug: connection.c:932: connection_handle_listener_read: Assertion ((struct sockaddr*)addrbuf)->sa_family == conn->socket_family failed; aborting.
It was preceded by quite a few of the following errors::
Aug 19 10:43:50.838 [Notice] dns_cancel_pending_resolve(): Bug: Address [scrubbed] is not pending (state 3). Dropping.
And quite possibly this was the start of the problems.
Aug 18 19:13:49.046 [Warning] eventdns: All nameservers have failed
Aug 18 19:13:51.912 [Notice] eventdns: Nameserver xxx.xxx.xxx.xxx is back up
Everything has been running smootly since.
I am running Tor 0.2.0.4-alpha (r11023)
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: user6362Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/482MSVC build failed since r108802020-06-27T14:10:35ZTracMSVC build failed since r10880MSVC build failed since r10880 because there's no s6_addr16 and s6_addr32 in MS Platform SDK.
structure details in MSDN:
http://msdn2.microsoft.com/en-us/library/ms738664.aspx
[Automatically added by flyspray2trac: Operating System: Wi...MSVC build failed since r10880 because there's no s6_addr16 and s6_addr32 in MS Platform SDK.
structure details in MSDN:
http://msdn2.microsoft.com/en-us/library/ms738664.aspx
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: roytam1Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/481Tor server complains about too less directory information, even if we are a s...2020-06-27T14:10:35ZTracTor server complains about too less directory information, even if we are a serverTor server complains about too less directory information to build a circuit, even if we are a server.
It is possible that you over read real problems because of this.
[Automatically added by flyspray2trac: Operating System: All]
**Tra...Tor server complains about too less directory information to build a circuit, even if we are a server.
It is possible that you over read real problems because of this.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Athaba0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/475version comparison2020-06-27T14:10:35Zweasel (Peter Palfrader)version comparisonchanged recommendedversions on tor26 to only recommend 0.1.2.16 and 0.2.0.4:
Fri 00:06:31 <weasel> it made tor's notice message change too:
Fri 00:06:41 <weasel> from: Aug 02 07:08:58.368 [notice] This version of Tor (0.2.0.3-alpha-dev)...changed recommendedversions on tor26 to only recommend 0.1.2.16 and 0.2.0.4:
Fri 00:06:31 <weasel> it made tor's notice message change too:
Fri 00:06:41 <weasel> from: Aug 02 07:08:58.368 [notice] This version of Tor (0.2.0.3-alpha-dev) is newer than any recommended version, according to
3/3 version-listing network statuses. Versions recommended by more than 1 authority are: 0.1.1.26, 0.1.2.13, 0.1.2.14, 0.1.2.15,
0.2.0.2-alpha, 0.2.0.3-alpha
Fri 00:07:00 <weasel> to Aug 02 19:41:32.354 [warn] Please upgrade! This version of Tor (0.2.0.3-alpha-dev) is not recommended, according to 3/3
version-listing network statuses. Versions recommended by at least 1 authority are: 0.1.1.26, 0.1.2.13, 0.1.2.14, 0.1.2.15,
0.2.0.2-alpha, 0.2.0.3-alpha
Fri 00:07:22 <weasel> which was kinda funny. please upgrade: here is a list of older versions that are recommended
[Automatically added by flyspray2trac: Operating System: All]0.2.0.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/473buffers.c:1606: assert_buf_ok: Assertion buf->cur < buf->mem+buf->len failed;...2020-06-27T14:10:35Zweasel (Peter Palfrader)buffers.c:1606: assert_buf_ok: Assertion buf->cur < buf->mem+buf->len failed; abortingon tor26, r11001, soon after starting:
Jul 31 04:21:03.510 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 31 04:21:06.991 [notice] Performing bandwidth self-test.....on tor26, r11001, soon after starting:
Jul 31 04:21:03.510 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 31 04:21:06.991 [notice] Performing bandwidth self-test...done.
Jul 31 04:21:09.585 [notice] Rejected router descriptor or extra-info from 64.62.190.36.
Jul 31 04:21:41.598 [notice] Rejected router descriptor or extra-info from 86.59.21.38.
Jul 31 04:21:41.638 [warn] http status 400 ("Extrainfo published time did not match routerdesc") response from dirserver '86.59.21.38:80'. Please correct.
Jul 31 04:25:24.936 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jul 31 04:29:18.359 [err] Bug: buffers.c:1606: assert_buf_ok: Assertion buf->cur < buf->mem+buf->len failed; aborting.
(gdb) bt
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7d3f885 in raise () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#2 0xb7d41002 in abort () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#3 0x0805038c in assert_buf_ok (buf=0x6) at buffers.c:1622
legacy/trac#4 0x080707ab in assert_connection_ok (conn=0xbea0da8, now=1185848958) at connection.c:2803
legacy/trac#5 0x0809bc09 in conn_write_callback (fd=372, events=4, _conn=0xbea0da8) at main.c:528
legacy/trac#6 0xb7f91c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#7 0xb7f91f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#8 0xb7f91dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0x0809d733 in do_main_loop () at main.c:1386
legacy/trac#10 0x0809e86d in tor_main (argc=0, argv=0x0) at main.c:2635
legacy/trac#11 0x080caa1b in main (argc=0, argv=0x0) at tor_main.c:28
legacy/trac#4 0x080707ab in assert_connection_ok (conn=0xbea0da8, now=1185848958) at connection.c:2803
2803 assert_buf_ok(conn->inbuf);
(gdb) p *conn
$1 = {magic = 2100428547, type = 4 '\004', state = 5 '\005', purpose = 0 '\0',
read_blocked_on_bw = 0, write_blocked_on_bw = 0,
hold_open_until_flushed = 0, inbuf_reached_eof = 0, edge_has_sent_end = 0,
edge_blocked_on_circ = 0, or_is_obsolete = 0, chosen_exit_optional = 0,
s = 372, conn_array_index = 260, read_event = 0x8796480,
write_event = 0x8796240, inbuf = 0x8795d68, outbuf = 0xb039370,
outbuf_flushlen = 512, timestamp_lastread = 1185848956,
timestamp_lastwritten = 1185848955, timestamp_created = 1185848571,
socket_family = 2, addr = 2620942612, port = 9001, marked_for_close = 0,
marked_for_close_file = 0x0, address = 0x9f00720 "156.56.105.20",
linked_conn = 0x0, linked = 0, reading_from_linked_conn = 0,
writing_to_linked_conn = 0, active_on_link = 0, dns_server_port = 0x0}
(gdb) p *conn->inbuf
$2 = {magic = 2969563922,
mem = 0x9ae7458 "[..cut by weasel...]",
cur = 0x9ae9458 "[..cut by weasel...] ", highwater = 0, len = 8192, memsize = 8192,
datalen = 0}
weasel@intrepid:~$ bc
ibase=16
9AE9458-9AE7458
8192
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/472space in SOURCE_ADDR in stream event2020-06-27T14:10:35ZRoger Dingledinespace in SOURCE_ADDR in stream event650 STREAM 232 NEW 0 128.31.0.34.$4C17FB532E20B2A8AC199441ECD2B0177B39E4B1.exit:9009 SOURCE_ADDR=(local link):0
We don't quite define an Address as something that has no spaces in it, but
something may still be wrong here. :)
How / whe...650 STREAM 232 NEW 0 128.31.0.34.$4C17FB532E20B2A8AC199441ECD2B0177B39E4B1.exit:9009 SOURCE_ADDR=(local link):0
We don't quite define an Address as something that has no spaces in it, but
something may still be wrong here. :)
How / whether to fix?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/471segfault while choosing nodes2020-06-27T14:10:36Zweasel (Peter Palfrader)segfault while choosing nodesOn tor26 on r10939 within seconds of starting Tor segfaults.
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0xb7d992de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7...On tor26 on r10939 within seconds of starting Tor segfaults.
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0xb7d992de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d98b1d in mallopt () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#2 0xb7d9950a in mallopt () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#3 0xb7d98135 in realloc () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#4 0x080c9fa8 in _tor_realloc (ptr=0x11, size=17) at util.c:149
legacy/trac#5 0x080d129e in smartlist_add (sl=0xb7e57f5c, element=0x15d2a318) at container.c:92
legacy/trac#6 0x08054501 in compute_preferred_testing_list (answer=0x9319d58 "") at circuitbuild.c:1533
legacy/trac#7 0x08054684 in choose_good_middle_server (purpose=17 '\021', state=0x8844378, head=0x8ee2b08, cur_len=0) at circuitbuild.c:1582
legacy/trac#8 0x08054ab4 in onion_extend_cpath (circ=0x87688e0) at circuitbuild.c:1693
legacy/trac#9 0x08051358 in onion_populate_cpath (circ=0x87688e0) at circuitbuild.c:269
legacy/trac#10 0x0805144c in circuit_establish_circuit (purpose=17 '\021', onehop_tunnel=17, exit=0x11, need_uptime=17, need_capacity=17, internal=17) at circuitbuild.c:315
legacy/trac#11 0x0805ca5e in circuit_launch_by_router (purpose=17 '\021', onehop_tunnel=17, exit=0x11, need_uptime=17, need_capacity=17, internal=17) at circuituse.c:809
legacy/trac#12 0x080ae71b in consider_testing_reachability (test_or=1, test_dir=1) at router.c:602
legacy/trac#13 0x08085b99 in connection_dir_client_reached_eof (conn=0x91f41e8) at directory.c:1306
legacy/trac#14 0x080865cf in connection_dir_reached_eof (conn=0x91f41e8) at directory.c:1476
legacy/trac#15 0x0806cd1c in connection_handle_read (conn=0x91f41e8) at connection.c:1817
legacy/trac#16 0x0809a779 in conn_read_callback (fd=1009, event=2, _conn=0x91f41e8) at main.c:498
legacy/trac#17 0xb7fa0c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#18 0xb7fa0f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#19 0xb7fa0dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
...
In this particular instance it had said 'smartlist_choose_by_bandwidth(): Bug:
Round-off error in computing bandwidth had an effect on which router we
chose.' (see bug legacy/trac#470) first, but it does not do this all the time.
After committing r1940 (the found=0 compile time warning), I got two different
backtraces:
(gdb) bt
#0 0xb7d372de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7d36b1d in mallopt () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#2 0xb7d3750a in mallopt () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#3 0xb7d36135 in realloc () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#4 0x080c9fb8 in _tor_realloc (ptr=0xb7df69e8, size=3084872168) at util.c:149
legacy/trac#5 0x080d12ae in smartlist_add (sl=0xb7df5f5c, element=0x2209b030) at container.c:92
legacy/trac#6 0x080b2ac0 in router_add_running_routers_to_smartlist (sl=0x875caa0, allow_invalid=0, need_uptime=1, need_capacity=1, need_guard=0) at routerlist.c:1103
legacy/trac#7 0x080b3232 in router_choose_random_node (preferred=0x0, excluded=0x0, excludedsmartlist=0x82cebe0, need_uptime=1, need_capacity=1, need_guard=0, allow_invalid=0, strict=0,
weight_for_exit=0) at routerlist.c:1412
legacy/trac#8 0x0805488b in choose_good_entry_server (purpose=5 '\005', state=0x87effa8) at circuitbuild.c:1642
legacy/trac#9 0x080549e5 in onion_extend_cpath (circ=0x85c2288) at circuitbuild.c:1689
legacy/trac#10 0x08051358 in onion_populate_cpath (circ=0x85c2288) at circuitbuild.c:269
legacy/trac#11 0x0805144c in circuit_establish_circuit (purpose=5 '\005', onehop_tunnel=-1210095128, exit=0xb7df69e8, need_uptime=-1210095128, need_capacity=-1210095128,
internal=-1210095128) at circuitbuild.c:315
legacy/trac#12 0x0805ca5e in circuit_launch_by_router (purpose=5 '\005', onehop_tunnel=-1210095128, exit=0xb7df69e8, need_uptime=-1210095128, need_capacity=-1210095128,
internal=-1210095128) at circuituse.c:809
legacy/trac#13 0x0805bebe in circuit_predict_and_launch_new () at circuituse.c:408
legacy/trac#14 0x0809ba11 in run_scheduled_events (now=1185498960) at main.c:1041
legacy/trac#15 0x0809bf03 in second_elapsed_callback (fd=-1, event=1, args=0x0) at main.c:1178
legacy/trac#16 0xb7f3ec79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#17 0xb7f3ef65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#18 0xb7f3edcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#19 0x0809c453 in do_main_loop () at main.c:1379
legacy/trac#20 0x0809d57d in tor_main (argc=-1210095128, argv=0xb7df69e8) at main.c:2622
legacy/trac#21 0x080c90fb in main (argc=-1210095128, argv=0xb7df69e8) at tor_main.c:28
and one with a broken stack frame:
(gdb) bt
#0 0xb7cc42de in mallopt () from /lib/tls/i686/cmov/libc.so.6
#1 0xb7cc3b1d in mallopt () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#2 0xb7cc2e83 in malloc () from /lib/tls/i686/cmov/libc.so.6
legacy/trac#3 0xb7dc648f in default_malloc_ex () from /usr/lib/i686/cmov/libcrypto.so.0.9.7
legacy/trac#4 0x000002c0 in ?? ()
legacy/trac#5 0x00000002 in ?? ()
legacy/trac#6 0xb7e93d24 in __JCR_LIST__ () from /usr/lib/i686/cmov/libcrypto.so.0.9.7
legacy/trac#7 0xb7dc60c3 in CRYPTO_malloc () from /usr/lib/i686/cmov/libcrypto.so.0.9.7
legacy/trac#8 0x000002c0 in ?? ()
[...]
legacy/trac#22 0x00000049 in ?? ()
legacy/trac#23 0xbfdf5fe8 in ?? ()
legacy/trac#24 0xb7cc2e83 in malloc () from /lib/tls/i686/cmov/libc.so.6
Previous frame inner to this frame (corrupt stack?)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/470segfault and Round-off error in computing bandwidth2020-06-27T14:10:36Zweasel (Peter Palfrader)segfault and Round-off error in computing bandwidthOn tor26 on r10939:
Jul 27 03:05:49.897 [notice] We now have enough directory information to build circuits.
Jul 27 03:06:23.138 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server des...On tor26 on r10939:
Jul 27 03:05:49.897 [notice] We now have enough directory information to build circuits.
Jul 27 03:06:23.138 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Jul 27 03:06:23.923 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Jul 27 03:06:27.332 [warn] smartlist_choose_by_bandwidth(): Bug: Round-off error in computing bandwidth had an effect on which router we chose. Please tell the developers.
[it also segfaults real soon after that, see bug legacy/trac#471]
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/469please limit connections by client2022-10-11T23:41:00Zweasel (Peter Palfrader)please limit connections by clientI just had 213.26.168.50 perform a denial of service against Tor26. It opened over
5000 connections to tor26, which not only ate a bit of CPU, but also used up all
available file descriptors, causing tor26 to drop new connections:
Jul 2...I just had 213.26.168.50 perform a denial of service against Tor26. It opened over
5000 connections to tor26, which not only ate a bit of CPU, but also used up all
available file descriptors, causing tor26 to drop new connections:
Jul 23 13:26:11.701 [notice] accept failed: Too many open files. Dropping incoming connection.
Please implement some limit of connections per clients. There are a few other
minor abusers too, which probably means this also could use some thinking at
the client:
sudo netstat -na | grep 86.59.21.38 > 38
cat 38 | grep ESTABLISHED | awk '{print $5}' | sed -e 's/:.*//' | sort | uniq -c | sort -n | tail
[..]
11 61.60.x.y [slightly anonymized]
13 212.249.x.y
16 59.120.x.y
19 81.120.x.y
25 65.122.x.y
31 202.185.x.y
32 125.16.x.y
5649 213.26.x.y
cheers,
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecified