Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:10:31Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/545updating guard status from v2 networkstatuses?2020-06-27T14:10:31ZRoger Dingledineupdating guard status from v2 networkstatuses?This is on my bridge, which is a relay plus dircache.
Nov 06 15:27:35.689 [info] connection_dir_client_reached_eof(): Received network
status objects (size 1729899) from server '128.31.0.34:9031'
Nov 06 15:27:35.720 [info] router_set_ne...This is on my bridge, which is a relay plus dircache.
Nov 06 15:27:35.689 [info] connection_dir_client_reached_eof(): Received network
status objects (size 1729899) from server '128.31.0.34:9031'
Nov 06 15:27:35.720 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "moria1" at 128.31.0.34:9031 (published 2007-11
-06 20:27:25)
Nov 06 15:27:35.803 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "tor26" at 86.59.21.38:80 (published 2007-11-06
20:26:19)
Nov 06 15:27:35.886 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "dizum" at 194.109.206.212:80 (published 2007-1
1-06 20:26:24)
Nov 06 15:27:35.967 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "moria2" at 128.31.0.34:9032 (published 2007-11
-06 20:26:30)
Nov 06 15:27:36.048 [info] router_set_networkstatus_v2(): Setting networkstatus
downloaded from directory server "lefkada" at 140.247.60.64:80 (published 2007-1
1-06 20:26:49)
Nov 06 15:27:36.107 [info] entry_guards_compute_status(): Summary: Entry 'sabota
ge' is reachable, unusable and not live.
Nov 06 15:27:36.107 [info] entry_guards_compute_status(): Summary: Entry 'teunto
rt' is reachable, usable and live.
...
It appears to be not only caching the v2 networkstatuses, but also looking at them
and acting on them?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/544bandwidth buckets are ints2020-06-27T14:10:31ZRoger Dingledinebandwidth buckets are intsNov 06 12:09:57.592 [debug] global_read_bucket now 6291456.
Nov 06 13:10:20.167 [debug] global_read_bucket now -1815240658.
Nov 06 13:10:20.167 [debug] global_write_bucket now -1815085682.
Nov 06 13:10:20.167 [debug] global_relayed_read...Nov 06 12:09:57.592 [debug] global_read_bucket now 6291456.
Nov 06 13:10:20.167 [debug] global_read_bucket now -1815240658.
Nov 06 13:10:20.167 [debug] global_write_bucket now -1815085682.
Nov 06 13:10:20.167 [debug] global_relayed_read_bucket now 512000.
Nov 06 13:10:20.167 [warn] Your system clock just jumped 3517 seconds forward; a
ssuming established circuits no longer work.
This overflow is probably a bug in 0.1.2.x too.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/541problem Toor with Avast2020-06-27T14:10:31ZTracproblem Toor with AvastHi all.
I have a problem between the tor.exe and from the avast-virus scanner called ashserv.exe.
When i started my system and i go to the Internet with firefox (avast is started from the autostart).
Next step i klick manually privoxy an...Hi all.
I have a problem between the tor.exe and from the avast-virus scanner called ashserv.exe.
When i started my system and i go to the Internet with firefox (avast is started from the autostart).
Next step i klick manually privoxy and vidalia.
After 10-20sek. the cpu goes up to 100% from ashserv.exe and when i killed tor.exe with the taskmanager
or the exit button from vidalia the cpu goes normally.
After 10-20min. later i run vidalia with the tor client and no problems.
But after 1-2 hour later the same problem.
I tried from the vidalia-bundle 01.2.15 to 17 and from the alpha 0.2.0.6 up to 0.2.0.8
Today i installed the alpha 0.2.0.9 (no problem in this minutes but... by all new installations from vidalia
my system goes normally.
But next day the same problem. :-(
My System:
3300+ Semperon
1Gig Ram
DSL
WinXP SP2
all updates from microsoft (I hope ore better not ;-) )
Avast 4.7 Home Edition
Sygate Personal Firewall
Firefox 2.0.0.8 with the torbutton 1.0.4.01
What can i do?
sincerely
Arkon1
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: arkon1https://gitlab.torproject.org/tpo/core/tor/-/issues/540Bug 499 not totally fixed - tor directory still created in %APPDATA%2020-06-27T14:10:31ZTracBug 499 not totally fixed - tor directory still created in %APPDATA%I originally reported bug 499 (I think that was the number) about a state file being created in %APPDATA% regardless of
the specified data directory in Vidalia -
o Minor bugfixes:
- Don't try to access (or alter) the state file when ...I originally reported bug 499 (I think that was the number) about a state file being created in %APPDATA% regardless of
the specified data directory in Vidalia -
o Minor bugfixes:
- Don't try to access (or alter) the state file when running
--list-fingerprint or --verify-config or --hash-password. Resolves
bug 499.
I say this is partially resolved because the state file is no longer created. However an empty 'tor' directory is still
created in %APPDATA% when Vidalia/Tor is run.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: wraithduhttps://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 Mathewson