Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:32Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/539Dirservers give 503 response, but include content anyway.2020-06-27T14:10:32ZNick MathewsonDirservers give 503 response, but include content anyway.Reported on frell2 by packbart. The server is running 0.1.2.18.
packbart@hendrek:~$ telnet 85.10.240.250 80
Trying 85.10.240.250...
Connected to 85.10.240.250.
Escape character is '!^]'.
GET /tor/server/d/C13519E867FB6761FC90A1CEA1E628...Reported on frell2 by packbart. The server is running 0.1.2.18.
packbart@hendrek:~$ telnet 85.10.240.250 80
Trying 85.10.240.250...
Connected to 85.10.240.250.
Escape character is '!^]'.
GET /tor/server/d/C13519E867FB6761FC90A1CEA1E628817B18EE9E+C5532C1E1D73F578A6C8E88D4365A61334820DBD+5E1920509A6B5C64C754EE7CE371249DDBE643F3+93EC21BD7AD05AF61829657E415CA9DF5ACD9D69.z HTTP/1.0
Host: 85.10.240.250
HTTP/1.1 503 Directory busy, try again later
Date: Wed, 31 Oct 2007 21:01:19 GMT
Vary: Accept-Encoding
X-Cache: MISS from www.anon-proxy.de
Connection: close
Content-Type: text/plain; charset=iso-8859-1
Content-Encoding: x-compress
router videoraptor 88.198.67.4 9003 0 9032
platform Tor 0.1.1.26 on Linux i686
published 2007-10-31 19:00:52
opt fingerprint 5F47 51CE 3E98 4306 B520 32DF 1CE5 1A67 F118 7C9F
uptime 4349911
bandwidth 92160 131072 112693
onion-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMF4Ut+axDUHZGVDzOm613YQ7e1Js0T1BKZR55fzK+XUqSHd9sFveH9R
MUsu0U/YLW6pSi/NGZyb8T4B8+JF1ehsUhcJF2Qz4HbZlvYT7x/j85PwN7l+/hze
TobTi6H9d6W1Nh6jNeHPmVPlYemGG/oOR0w43EIt0OrGM7z6fLhhAgMBAAE=
-----END RSA PUBLIC KEY-----
signing-key
-----BEGIN RSA PUBLIC KEY-----
MIGJAoGBAMsEyOXG/RRht13cHiEmJgJ1+rn1Y5tldYTZzlMpv8m5ms9T2n2TB3BF
[...]
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/538[un]named_server_map should never be null.2020-06-27T14:10:32ZNick Mathewson[un]named_server_map should never be null.If no consensus exists, router_reload_consensus_networkstatus() does nothing. Instead, it should initialize
static fields in networkstatus.c that are used for nickname lookup. named_server_map should never be NULL, as it
was in the bug...If no consensus exists, router_reload_consensus_networkstatus() does nothing. Instead, it should initialize
static fields in networkstatus.c that are used for nickname lookup. named_server_map should never be NULL, as it
was in the bug reported by Fabian Keil on or-talk at 27 Oct 2007.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/536memory leak in trusted_dirs_load_certs_from_string2020-06-27T14:10:32ZRoger Dingledinememory leak in trusted_dirs_load_certs_from_string==25743== 4,490 (3,978 direct, 512 indirect) bytes in 10 blocks are definitely l
ost in loss record 7 of 9
==25743== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==25743== by 0x80EBB6C: _tor_malloc (util.c:112)
==25743== by 0x...==25743== 4,490 (3,978 direct, 512 indirect) bytes in 10 blocks are definitely l
ost in loss record 7 of 9
==25743== at 0x401D38B: malloc (vg_replace_malloc.c:149)
==25743== by 0x80EBB6C: _tor_malloc (util.c:112)
==25743== by 0x80DDCC3: authority_cert_parse_from_string (routerparse.c:1496)
==25743== by 0x80CD999: trusted_dirs_load_certs_from_string (routerlist.c:113
)
==25743== by 0x80CD946: trusted_dirs_reload_certs (routerlist.c:96)
==25743== by 0x80B01D4: do_main_loop (main.c:1347)
==25743== by 0x80B1766: tor_main (main.c:1932)
==25743== by 0x80EABB5: main (tor_main.c:28)
Looking at trusted_dirs_load_certs_from_string(), towards the bottom it calls
cert->cache_info.signed_descriptor_body = tor_strndup(s, eos-s);
yet in authority_cert_parse_from_string() we already
cert->cache_info.signed_descriptor_body = tor_malloc(len+1);
memcpy(cert->cache_info.signed_descriptor_body, s, len);
cert->cache_info.signed_descriptor_body[len] = 0;
It seems that we should do only one of these?
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/534tor clients stop working if one v3 authority goes away for 3 hours2020-06-27T14:10:32ZRoger Dingledinetor clients stop working if one v3 authority goes away for 3 hoursIf one of the v3 authorities goes away, clients that use the v3 consensus
will fail to have a live one, and will refuse to build circuits.
We should make clients tolerate this by using an older consensus if they've
got it. I think "at m...If one of the v3 authorities goes away, clients that use the v3 consensus
will fail to have a live one, and will refuse to build circuits.
We should make clients tolerate this by using an older consensus if they've
got it. I think "at most 24 hours old" is a fine estimate -- not so high
that it will point to useless descriptors, and not so low that a bit of
downtime on the part of the authorities will be a killer.
Of course, this comes with an anonymity downside: the directory mirrors
can try to trick you into using an old consensus. Perhaps if we get an old
consensus then we should go straight to an authority for the next try (or
after a few tries), and then consider any one we get from an authority to
be safe?
When there are 10 authorities and it becomes clear that a majority of them
never vanish, we should then consider removing this feature, since the
anonymity risk will then outweigh the "it works" benefit. But for now, I
think 0.2.0.9-alpha clients will be much happier having this feature.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/533mmap failure complaints too loud2020-06-27T14:10:32ZRoger Dingledinemmap failure complaints too loudOct 23 23:37:44.983 [info] tor_mmap_file(): File "/home/arma/.tor/cached-descrip
tors" is empty. Ignoring.
Oct 23 23:37:44.983 [warn] Unable to mmap new descriptor file at '/home/arma/.to
r/cached-descriptors'.
Perhaps tor_mmap_file sho...Oct 23 23:37:44.983 [info] tor_mmap_file(): File "/home/arma/.tor/cached-descrip
tors" is empty. Ignoring.
Oct 23 23:37:44.983 [warn] Unable to mmap new descriptor file at '/home/arma/.to
r/cached-descriptors'.
Perhaps tor_mmap_file should have a tristate return value -- I succeeded, I failed
but that's ok, and I failed horribly?
(Is there any point to that third state?)
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/529v3 client confused about which servers are named2020-06-27T14:10:33ZRoger Dingledinev3 client confused about which servers are namedRunning r11968 as a client, it complains about things like
Oct 16 01:05:36.303 [warn] You specified a server "DrazziBTorNode" by name, but
this name is not registered, so it could be used by any server, not just the one
you meant. To m...Running r11968 as a client, it complains about things like
Oct 16 01:05:36.303 [warn] You specified a server "DrazziBTorNode" by name, but
this name is not registered, so it could be used by any server, not just the one
you meant. To make sure you get the same server in the future, refer to it by k
ey, as "$F268430A96705AC0BB52117AC5122F4DC934727E".
It turns out this is caused by vidalia doing a getinfo on this nickname.
I caught Tor while Vidalia was asking about Bellum:
#0 router_get_by_nickname (nickname=0x8306672 "Bellum", warn_if_unnamed=1)
at routerlist.c:1783
#1 0x08083c5e in getinfo_helper_dir (control_conn=0x8681e20,
question=0x8306668 "desc/name/Bellum", answer=0xbfc4342c) at control.c:1314
legacy/trac#2 0x08085d1b in handle_getinfo_helper (control_conn=0x8681e20,
question=0x8306668 "desc/name/Bellum", answer=0xbfc4342c) at control.c:1804
legacy/trac#3 0x08085df0 in handle_control_getinfo (conn=0x8681e20, len=19,
body=0x8adda00 "desc/name/Bellum\r\n") at control.c:1829
legacy/trac#4 0x08088670 in connection_control_process_inbuf (conn=0x8681e20)
at control.c:2685
legacy/trac#5 0x0807442e in connection_process_inbuf (conn=0x8681e20, package_partial=1)
at connection.c:2638
legacy/trac#6 0x080725a1 in connection_handle_read (conn=0x8681e20) at connection.c:1813
legacy/trac#7 0x080adfc0 in conn_read_callback (fd=24, event=2, _conn=0x8681e20)
at main.c:470
legacy/trac#8 0xb7ee6c79 in event_base_priority_init () from /usr/lib/libevent-1.1a.so.1
legacy/trac#9 0xb7ee6f65 in event_base_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#10 0xb7ee6dcb in event_loop () from /usr/lib/libevent-1.1a.so.1
legacy/trac#11 0x080afe3b in do_main_loop () at main.c:1389
legacy/trac#12 0x080b127d in tor_main (argc=1, argv=0xbfc43804) at main.c:1928
legacy/trac#13 0x080e90e2 in main (argc=Cannot access memory at address 0x0
) at tor_main.c:28
It turns out there was a circuit building at that time:
Oct 16 01:26:41.539 [info] exit (high-uptime) circ (length 3, exit chaoscomputer
club23): $5C854C6CE50727F32E51274B1CF4DF9693A206EA(open) Bellum(open) $4121B07A3
86AA1A8015D618D213B1980BA388487(closed)
Now, clearly some part of Tor thought Bellum was Named, so it used the nickname.
But then the other part of Tor thought it wasn't.
In this case, the cached-consensus file said
r Bellum 7j/MKmnxheiRBy8T7pkIzW7ZvqU 22tvSKhAXrqKWmvs53JdUlWDr70 2007-10-15 22:2
7:52 62.75.223.163 9001 9030
s Fast Guard Named Running Stable V2Dir Valid
v Tor 0.1.2.14
but in my cached-status/* directories, which haven't been updated in a few hours
since I'm allegedly not using them anymore, tor26's networkstatus didn't have
an entry for Bellum -- so according to v2 it wouldn't be considered Named.
[Automatically added by flyspray2trac: Operating System: All]Nick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/528failure case memory leak in base32_decode2020-06-27T14:10:33ZTracfailure case memory leak in base32_decodeIt's trivial, but base32_decode mallocates a "tmp" variable which is not freed in the "illegal character in base32 encoded string" case.
...
/* Convert base32 encoded chars to the 5-bit values that they represent. */
tmp = tor_mallo...It's trivial, but base32_decode mallocates a "tmp" variable which is not freed in the "illegal character in base32 encoded string" case.
...
/* Convert base32 encoded chars to the 5-bit values that they represent. */
tmp = tor_malloc_zero(srclen);
for (j = 0; j < srclen; ++j) {
if (src[j] > 0x60 && src[j] < 0x7B) tmp[j] = src[j] - 0x61;
else if (src[j] > 0x31 && src[j] < 0x38) tmp[j] = src[j] - 0x18;
else {
log_warn(LD_BUG, "illegal character in base32 encoded string");
return -1;
}
}
...
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: ghazelhttps://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/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/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]