The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:10:50Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/341Mac OS X: bad permissions for log file2020-06-27T14:10:50ZTracMac OS X: bad permissions for log fileFollowing Apple guidelines, the location of Tor log file is incorrect (should be in /var/log/). A link is made from /var/log/tor to //Library/Tor/var/log/tor.
However, permissions are wrong when compared to other system logs and applicat...Following Apple guidelines, the location of Tor log file is incorrect (should be in /var/log/). A link is made from /var/log/tor to //Library/Tor/var/log/tor.
However, permissions are wrong when compared to other system logs and application Console.app cannot read it. File should be owned by root:admin
and permissions set to -rw-r-----
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: Steff-XAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/342No connections after start of next interval of AccountingStart?2020-06-27T14:10:50ZTracNo connections after start of next interval of AccountingStart?The server 'roundabout' started a new interval on 4th Oct. 00:00.
By this time no traffic amount is logged as related to Tor (as of 4th Oct. 18:38) although notices.log
shows the messages that the server should be waked up at 08:05:24 l...The server 'roundabout' started a new interval on 4th Oct. 00:00.
By this time no traffic amount is logged as related to Tor (as of 4th Oct. 18:38) although notices.log
shows the messages that the server should be waked up at 08:05:24 local time.
torrc has the following settings:
AccountingStart month 4 00:00
AccountingMax 145 GB
The file /var/log/tor/notices.log shows the following:
---snip---
Oct 04 00:00:00.011 [notice] accounting_set_wakeup_time(): Configured hibernation. This interval began at 2006-10-04 00:00:00; the scheduled wake-up time is 2006-10-04 08:05:24; we expect to exhaust our quota for this interval around 2006-11-03 20:43:24; the next interval begins at 2006-11-04 00:00:00 (all times local)
Oct 04 00:00:01.031 [notice] consider_hibernation(): Commencing hibernation. We will wake up at 2006-10-04 08:05:24 local time.
Oct 04 00:00:01.031 [notice] hibernate_go_dormant(): Going dormant. Blowing away remaining connections.
Oct 04 00:26:28.771 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 00:56:57.609 [notice] I learned some more directory information, but not enough to build a circuit.
[....]
Oct 04 07:44:40.899 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 08:15:10.531 [notice] I learned some more directory information, but not enough to build a circuit.
[....]
Oct 04 17:30:22.398 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 18:00:54.076 [notice] I learned some more directory information, but not enough to build a circuit.
Oct 04 18:31:24.745 [notice] I learned some more directory information, but not enough to build a circuit.
---snap---
[....] means the messages repeated with different timestamps.
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Maschi0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/344tor terminates when running out of memory2020-06-27T14:10:50ZTractor terminates when running out of memoryI am running a tor 0.1.1.24-1~~sarge.1 server on a virtual server (OpenVZ).
One thing about OpenVZ is that the amount of memory available to the virtual machine varies all the time.
The server shuts down when it runs out of memory:
Logf...I am running a tor 0.1.1.24-1~~sarge.1 server on a virtual server (OpenVZ).
One thing about OpenVZ is that the amount of memory available to the virtual machine varies all the time.
The server shuts down when it runs out of memory:
Logfile entry:
Oct xx xx:xx:xx.xxx [err] _tor_realloc(): Out of memory. Dying.
I would like tor to keep running when it runs out of memory - perhaps it can just close a few connections,
stop accepting new connections for a while, discard some buffers etc?
Tor terminating because it runs out of memory is not listed at
http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#head-43d0c843cb6c453ad1231c48c11196a46fae9540
so I think perhaps this is a bug?
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: snpost 0.2.0.xNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/346memory leak in router_rebuild_store() in routerlist.c2020-06-27T14:10:50ZTracmemory leak in router_rebuild_store() in routerlist.ctor/src/or % cat routerlist.c.diff
268c268
< smartlist_t *lst = smartlist_create();
---
> smartlist_t *lst;
283d282
< smartlist_free(lst);
321,322d319
< smartlist_free(old_routers);
< smartlist_free(routers);
333a331...tor/src/or % cat routerlist.c.diff
268c268
< smartlist_t *lst = smartlist_create();
---
> smartlist_t *lst;
283d282
< smartlist_free(lst);
321,322d319
< smartlist_free(old_routers);
< smartlist_free(routers);
333a331,332
> smartlist_free(old_routers);
> smartlist_free(routers);
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: fookoowahttps://gitlab.torproject.org/tpo/core/tor/-/issues/347Some controller signals only work on unix2020-06-27T14:10:50ZRoger DingledineSome controller signals only work on unixcontrol_signal_check() and control_signal_act hard-code the
signal numbers to be the ones used in unix.
But handle_control_signal() uses the system-defined values for them.
One of these behaviors is wrong.
E.g., USR1 and USR2 (among p...control_signal_check() and control_signal_act hard-code the
signal numbers to be the ones used in unix.
But handle_control_signal() uses the system-defined values for them.
One of these behaviors is wrong.
E.g., USR1 and USR2 (among possibly others) don't work on OS X from the
controller.
[Automatically added by flyspray2trac: Operating System: All]0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/348Excessive loggin at warning2020-06-27T14:10:50ZTracExcessive loggin at warningActual version is 23, not 24. Installed with vidalia package pre-made for Mac Os X.
Problem: I'm getting LOTS of log messages like:
Oct 25 08:17:16 stbmac Tor[14520]: add_nickname_list_to_smartlist(): Nickname list includes 'serifos' w...Actual version is 23, not 24. Installed with vidalia package pre-made for Mac Os X.
Problem: I'm getting LOTS of log messages like:
Oct 25 08:17:16 stbmac Tor[14520]: add_nickname_list_to_smartlist(): Nickname list includes 'serifos' which is known but down.\n
Oct 25 08:17:17 stbmac Tor[14520]: add_nickname_list_to_smartlist(): Nickname list includes 'lefkada' which is known but down.\n
These go away if I tell my system to stop using tor. I get these every time
something on my system that pays attention to my HTTP proxy settings tries
to open a connection.
In my config file, I have EntryNodes and ExitNodes set to a large set of
high bandwidth nodes located on my continent (as an attempt to make Tor run
faster -- it was too slow out of the box with no config help).
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: keybounce0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/349getinfo network-status sometimes returns an incomplete list2020-06-27T14:10:49Zedmanmgetinfo network-status sometimes returns an incomplete listSometimes Tor's response to a "getinfo network-status" does not appear to include all known OR identities.
Some servers may not be included in the returned list, even though Tor has built circuits through them. Sometimes
the returned l...Sometimes Tor's response to a "getinfo network-status" does not appear to include all known OR identities.
Some servers may not be included in the returned list, even though Tor has built circuits through them. Sometimes
the returned list is entirely empty, even though Tor has built circuits and displayed its happy "Tor has
successfully opened a circuit" message.
Here is an example:
getinfo network-status
250-network-status=autonomynodev2=$EFE988B0EF6A708F5BB6A843AC507604D0C38239 KB=$C938A72F7E0333CEF5AA7C0B45FC74EF4E02F55D HaschMichMaedc
hen=$F9D4EC6EAC081C3F26BF703932B07BB1B161F22F histor2=$3276923C1617879D3246133BD37111A661461382 hppie=$BBEB4939DF13BAC358DF49608C3B760A
A6047EAB $D8632EAE2A5CA7BA147AB5489D43B5E2E80C37D7 $02FF7F59145E4917321739947585C757B22B4008 $1783E1CD818BB74FB20FE46E7317FBC26D13172E
$519C8B8E1A51F3D2593B6675A9768D83F9F041CB $999C4E1F995A0714E7D64E8A6CD09AC4490E72D6
250 OK
getinfo circuit-status
250+circuit-status=
7 BUILT freetux4ever,enterprise,utcluj
5 BUILT freetux4ever,spinell,waabbeel
4 BUILT myrandomnode,spinell,Tonga
3 BUILT myrandomnode,l3cht3rn3t,idbsgetyrubdgretyrw
.
250 OK
Tor returned a list of ten servers and has currently built four circuits using nine distinct servers. Doing a
"getinfo desc/id/<keyid>" for each of the non-Named servers above told me they have the following nicknames:
nonec549299e43~$D8632EAE2A5CA7BA147AB5489D43B5E2E80C37D7
QuePuedo~$02FF7F59145E4917321739947585C757B22B4008
kazol~$1783E1CD818BB74FB20FE46E7317FBC26D13172E
hiball~$519C8B8E1A51F3D2593B6675A9768D83F9F041CB
farse~$999C4E1F995A0714E7D64E8A6CD09AC4490E72D6
We see that the set of servers returned by "getinfo network-status" and the set of servers through which we
have built circuits are even disjoint, in this case.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/350infinite loop on evil controlport input2020-06-27T14:10:49ZRoger Dingledineinfinite loop on evil controlport inputecho -ne "authenticate\r\nsignal newnym\r\nquit\r\n" | telnet localhost 9051
telnet seems to replace the first \n with a \0. I'm not sure why. But when
it does, Tor gets stuck in a loop in find_crlf_on_buf().
r8843 contains a fix to ma...echo -ne "authenticate\r\nsignal newnym\r\nquit\r\n" | telnet localhost 9051
telnet seems to replace the first \n with a \0. I'm not sure why. But when
it does, Tor gets stuck in a loop in find_crlf_on_buf().
r8843 contains a fix to make Tor not die. Is this the right fix? Is there more
to fix?
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/tpo/core/tor/-/issues/351_circuit_mark_for_close(): Reason 9 out of range at command.c:3782020-06-27T14:10:49ZTrac_circuit_mark_for_close(): Reason 9 out of range at command.c:378Hi,
On server roundabout in notices.log the following messages appears more or less regularly:
---snip---
Oct 31 20:24:00.374 [warn] _circuit_mark_for_close(): Reason 9 out of range at command.c:378
---snap---
The server is connectable...Hi,
On server roundabout in notices.log the following messages appears more or less regularly:
---snip---
Oct 31 20:24:00.374 [warn] _circuit_mark_for_close(): Reason 9 out of range at command.c:378
---snap---
The server is connectable and in use (tested with tcpdump) although it is not listed on http://torstat.xenobite.eu/ anymore.
Regards,
Joerg
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Maschihttps://gitlab.torproject.org/tpo/core/tor/-/issues/352Vidalia wont start2020-06-27T14:10:49ZTracVidalia wont startAfter instaling the Vidalia download I receive the following error -
vidalia.exe
vidalia.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
P. S. I have a saved screen image that shows the exact ...After instaling the Vidalia download I receive the following error -
vidalia.exe
vidalia.exe has encountered a problem and needs to close. We are sorry for the inconvenience.
P. S. I have a saved screen image that shows the exact error, if that will help.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: hexadecimatorAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/353Tor-0.1.2.2-alpha-win32 wont do .onion2020-06-27T14:10:49ZTracTor-0.1.2.2-alpha-win32 wont do .onionI tried to use the Tor-0.1.2.2-alpha-win32 package and all seemed to work as normal but...
I was unable to connect to .onion sites.
At first i thought i did something wrong but after degrading to 0.1.1.24 with unaltered config i was abl...I tried to use the Tor-0.1.2.2-alpha-win32 package and all seemed to work as normal but...
I was unable to connect to .onion sites.
At first i thought i did something wrong but after degrading to 0.1.1.24 with unaltered config i was able to.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: TriMoonAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/354Web based config/status interface2020-06-27T14:10:49ZTracWeb based config/status interfaceI think it would be very beneficial to everyone using tor to have a web based config/report functionality built into tor.
The most logical URL would then be "config.onion" and "status.onion".
This will eliminate all the different client...I think it would be very beneficial to everyone using tor to have a web based config/report functionality built into tor.
The most logical URL would then be "config.onion" and "status.onion".
This will eliminate all the different clients used to control tor.
Ofcourse the control port should remain operational for a while to let users have an option to adjust and shift to the new way...
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: TriMoonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/355tor server crashes after an hour2020-06-27T14:10:49ZTractor server crashes after an hourI've set up a tor server with both the latest stable and newest alpha versions. Both crash after about the same amount of time. The error in the log is:
Nov 03 23:19:06:199 [Error] do_main_loop(): libevent call with win32 failed: Invalid...I've set up a tor server with both the latest stable and newest alpha versions. Both crash after about the same amount of time. The error in the log is:
Nov 03 23:19:06:199 [Error] do_main_loop(): libevent call with win32 failed: Invalid argument [WSAEINVAL ] [10022]
In the alpha version there was a similar error related to libevent.
I saw libevent mentioned in the wiki on reporting a bug, but it didn't tell me how I would update something like that.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]
**Trac**:
**Username**: darkmagessAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/356Windows nt service will not read torrc in Document and Settings directory2020-06-27T14:10:48ZEugene VassermanWindows nt service will not read torrc in Document and Settings directoryIf a Windows service is added using Tor, the command line looks like this:
tor -nt_service -f "C:\Document and Settings\username\Application Data\Tor\torrc".
However, attempting to start the service yields a "System could not find the fi...If a Windows service is added using Tor, the command line looks like this:
tor -nt_service -f "C:\Document and Settings\username\Application Data\Tor\torrc".
However, attempting to start the service yields a "System could not find the file specified" error.
Running the very same command in the cmd window works, though. also, placing a torrc file into the
tor program directory makes it work. Changing the credentials under which the service runs makes no difference.
Please contact me if further details are needed.
[Automatically added by flyspray2trac: Operating System: Windows 2k/XP]0.1.2.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/358Segmentation fault on tor server 0.1.1.252020-06-27T14:10:48ZTracSegmentation fault on tor server 0.1.1.25Hi,
I got a segfault with the debian package on an GNU/Linux debian sarge system. Tor crash after 5-7 hour. Hiere the output:
---cut
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the ...Hi,
I got a segfault with the debian package on an GNU/Linux debian sarge system. Tor crash after 5-7 hour. Hiere the output:
---cut
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...tor: Datei oder Verzeichnis nicht gefunden.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
Core was generated by `/usr/sbin/tor'.
Program terminated with signal 11, Segmentation fault.
#0 0x08082862 in ?? ()
(gdb)
---cut
after typing "bt":
---cut
#0 0x08082862 in ?? ()
#1 0x0939f188 in ?? ()
legacy/trac#2 0x00000000 in ?? ()
legacy/trac#3 0x00000000 in ?? ()
legacy/trac#4 0x080a5ecd in ?? ()
legacy/trac#5 0x00000006 in ?? ()
legacy/trac#6 0x00000004 in ?? ()
legacy/trac#7 0x080c1e00 in ?? ()
legacy/trac#8 0x089690d0 in ?? ()
legacy/trac#9 0x00000004 in ?? ()
legacy/trac#10 0x080ce96b in ?? ()
legacy/trac#11 0xbffffcb8 in ?? ()
legacy/trac#12 0x080870c7 in ?? ()
legacy/trac#13 0x089690d0 in ?? ()
legacy/trac#14 0x455337de in ?? ()
legacy/trac#15 0xbffffca8 in ?? ()
legacy/trac#16 0x08068f66 in ?? ()
legacy/trac#17 0x0939f188 in ?? ()
legacy/trac#18 0x080f1880 in ?? ()
legacy/trac#19 0xbffffca8 in ?? ()
legacy/trac#20 0x080a5ecd in ?? ()
legacy/trac#21 0x00000007 in ?? ()
legacy/trac#22 0x0000006f in ?? ()
legacy/trac#23 0x00000004 in ?? ()
legacy/trac#24 0x089690d0 in ?? ()
legacy/trac#25 0x00000000 in ?? ()
legacy/trac#26 0x089690d0 in ?? ()
legacy/trac#27 0xbffffcd8 in ?? ()
legacy/trac#28 0x00000000 in ?? ()
legacy/trac#29 0x089a3430 in ?? ()
legacy/trac#30 0x080f1880 in ?? ()
legacy/trac#31 0xbffffcd8 in ?? ()
legacy/trac#32 0x08086dd4 in ?? ()
legacy/trac#33 0x0000024d in ?? ()
legacy/trac#34 0xbffffcd8 in ?? ()
legacy/trac#35 0x00000001 in ?? ()
legacy/trac#36 0x401bbac0 in ?? ()
legacy/trac#37 0x401bbac0 in ?? ()
legacy/trac#38 0x401bbac0 in ?? ()
legacy/trac#39 0xbffffd08 in ?? ()
legacy/trac#40 0x401b6c79 in ?? ()
legacy/trac#41 0x000000ac in ?? ()
legacy/trac#42 0x00000004 in ?? ()
legacy/trac#43 0x089690d0 in ?? ()
legacy/trac#44 0xbffffcf0 in ?? ()
legacy/trac#45 0x455337de in ?? ()
legacy/trac#46 0xbffffcfe in ?? ()
legacy/trac#47 0x080f2b90 in ?? ()
legacy/trac#48 0x0000bac0 in ?? ()
legacy/trac#49 0xbffffd40 in ?? ()
legacy/trac#50 0x080f1880 in ?? ()
legacy/trac#51 0xbffffd58 in ?? ()
legacy/trac#52 0x401b6f65 in ?? ()
legacy/trac#53 0x080f1880 in ?? ()
legacy/trac#54 0x080f18b8 in ?? ()
legacy/trac#55 0xbffffd40 in ?? ()
legacy/trac#56 0x4000baa3 in ?? ()
legacy/trac#57 0x4015f67c in ?? ()
legacy/trac#58 0x401bbae4 in ?? ()
legacy/trac#59 0x0000002a in ?? ()
legacy/trac#60 0x00000000 in ?? ()
legacy/trac#61 0x080f18b8 in ?? ()
legacy/trac#62 0x401bb9b0 in ?? ()
legacy/trac#63 0x00000000 in ?? ()
legacy/trac#64 0x00016822 in ?? ()
legacy/trac#65 0x00000000 in ?? ()
legacy/trac#66 0x00064b26 in ?? ()
legacy/trac#67 0xbffffd80 in ?? ()
legacy/trac#68 0x401bbac0 in ?? ()
legacy/trac#69 0x40016540 in ?? ()
legacy/trac#70 0xbffffe44 in ?? ()
legacy/trac#71 0xbffffd78 in ?? ()
legacy/trac#72 0x401b6dcb in ?? ()
legacy/trac#73 0x080f1880 in ?? ()
legacy/trac#74 0x00000000 in ?? ()
legacy/trac#75 0xbffffd80 in ?? ()
legacy/trac#76 0x080f18ac in ?? ()
legacy/trac#77 0x401b6da0 in ?? ()
legacy/trac#78 0x401bbac0 in ?? ()
legacy/trac#79 0xbffffd88 in ?? ()
legacy/trac#80 0x401b6cb0 in ?? ()
legacy/trac#81 0x00000000 in ?? ()
legacy/trac#82 0x402ebc80 in ?? ()
legacy/trac#83 0xbffffdb8 in ?? ()
legacy/trac#84 0x0808849b in ?? ()
legacy/trac#85 0x00000000 in ?? ()
legacy/trac#86 0x00000000 in ?? ()
legacy/trac#87 0x00000000 in ?? ()
legacy/trac#88 0x08088fb4 in ?? ()
legacy/trac#89 0x00000000 in ?? ()
legacy/trac#90 0xbffffe44 in ?? ()
legacy/trac#91 0x080ce660 in ?? ()
legacy/trac#92 0x080bdbcf in ?? ()
legacy/trac#93 0x402eb8c0 in ?? ()
legacy/trac#94 0x40016540 in ?? ()
legacy/trac#95 0xbffffdd8 in ?? ()
legacy/trac#96 0x08089465 in ?? ()
legacy/trac#97 0x00000001 in ?? ()
legacy/trac#98 0xbffffe44 in ?? ()
legacy/trac#99 0xbffffde8 in ?? ()
legacy/trac#100 0x080b733b in ?? ()
legacy/trac#101 0x402eb8c0 in ?? ()
legacy/trac#102 0x080b7380 in ?? ()
legacy/trac#103 0xbffffde8 in ?? ()
legacy/trac#104 0x080a5b8b in ?? ()
legacy/trac#105 0x00000001 in ?? ()
legacy/trac#106 0xbffffe44 in ?? ()
legacy/trac#107 0xbffffe18 in ?? ()
legacy/trac#108 0x401d1e36 in ?? ()
legacy/trac#109 0x00000001 in ?? ()
legacy/trac#110 0xbffffe44 in ?? ()
legacy/trac#111 0xbffffe4c in ?? ()
legacy/trac#112 0x0804c550 in ?? ()
legacy/trac#113 0x00000000 in ?? ()
legacy/trac#114 0x4000bcd0 in ?? ()
legacy/trac#115 0x402ecdb4 in ?? ()
legacy/trac#116 0x40016ca0 in ?? ()
legacy/trac#117 0x00000001 in ?? ()
legacy/trac#118 0x0804c550 in ?? ()
legacy/trac#119 0x00000000 in ?? ()
legacy/trac#120 0x0804c571 in ?? ()
legacy/trac#121 0x080a5b70 in ?? ()
legacy/trac#122 0x00000001 in ?? ()
legacy/trac#123 0xbffffe44 in ?? ()
legacy/trac#124 0x080b7320 in ?? ()
legacy/trac#125 0x080b7380 in ?? ()
legacy/trac#126 0x4000c380 in ?? ()
legacy/trac#127 0xbffffe3c in ?? ()
legacy/trac#128 0x00000000 in ?? ()
legacy/trac#129 0x00000001 in ?? ()
legacy/trac#130 0xbfffff13 in ?? ()
legacy/trac#131 0x00000000 in ?? ()
legacy/trac#132 0xbfffff21 in ?? ()
legacy/trac#133 0xbfffff28 in ?? ()
legacy/trac#134 0xbfffff33 in ?? ()
legacy/trac#135 0xbfffff43 in ?? ()
legacy/trac#136 0xbfffff4d in ?? ()
legacy/trac#137 0xbfffff8f in ?? ()
legacy/trac#138 0xbfffffa3 in ?? ()
legacy/trac#139 0xbfffffb4 in ?? ()
legacy/trac#140 0xbfffffbf in ?? ()
legacy/trac#141 0xbfffffc7 in ?? ()
legacy/trac#142 0xbfffffd4 in ?? ()
legacy/trac#143 0x00000000 in ?? ()
legacy/trac#144 0x00000010 in ?? ()
legacy/trac#145 0x178bfbff in ?? ()
legacy/trac#146 0x00000006 in ?? ()
legacy/trac#147 0x00001000 in ?? ()
legacy/trac#148 0x00000011 in ?? ()
legacy/trac#149 0x00000064 in ?? ()
legacy/trac#150 0x00000003 in ?? ()
legacy/trac#151 0x08048034 in ?? ()
legacy/trac#152 0x00000004 in ?? ()
legacy/trac#153 0x00000020 in ?? ()
legacy/trac#154 0x00000005 in ?? ()
legacy/trac#155 0x00000008 in ?? ()
legacy/trac#156 0x00000007 in ?? ()
legacy/trac#157 0x40000000 in ?? ()
legacy/trac#158 0x00000008 in ?? ()
legacy/trac#159 0x00000000 in ?? ()
legacy/trac#160 0x00000009 in ?? ()
legacy/trac#161 0x0804c550 in ?? ()
legacy/trac#162 0x0000000b in ?? ()
legacy/trac#163 0x0000006e in ?? ()
legacy/trac#164 0x0000000c in ?? ()
legacy/trac#165 0x0000006e in ?? ()
legacy/trac#166 0x0000000d in ?? ()
legacy/trac#167 0x0000006e in ?? ()
legacy/trac#168 0x0000000e in ?? ()
legacy/trac#169 0x0000006e in ?? ()
legacy/trac#170 0x0000000f in ?? ()
legacy/trac#171 0xbfffff0e in ?? ()
legacy/trac#172 0x00000000 in ?? ()
legacy/trac#173 0x00000000 in ?? ()
legacy/trac#174 0x00000000 in ?? ()
legacy/trac#175 0x00000000 in ?? ()
legacy/trac#176 0x00000000 in ?? ()
legacy/trac#177 0x00000000 in ?? ()
legacy/trac#178 0x00000000 in ?? ()
legacy/trac#179 0x00000000 in ?? ()
legacy/trac#180 0x36690000 in ?? ()
legacy/trac#181 0x2f003638 in ?? ()
legacy/trac#182 0x2f727375 in ?? ()
legacy/trac#183 0x6e696273 in ?? ()
legacy/trac#184 0x726f742f in ?? ()
legacy/trac#185 0x3d5a4800 in ?? ()
legacy/trac#186 0x00303031 in ?? ()
legacy/trac#187 0x4d524554 in ?? ()
legacy/trac#188 0x6574783d in ?? ()
legacy/trac#189 0x53006d72 in ?? ()
legacy/trac#190 0x4c4c4548 in ?? ()
legacy/trac#191 0x69622f3d in ?? ()
legacy/trac#192 0x61622f6e in ?? ()
legacy/trac#193 0x55006873 in ?? ()
legacy/trac#194 0x3d524553 in ?? ()
legacy/trac#195 0x746f6f72 in ?? ()
legacy/trac#196 0x54415000 in ?? ()
legacy/trac#197 0x752f3d48 in ?? ()
legacy/trac#198 0x6c2f7273 in ?? ()
legacy/trac#199 0x6c61636f in ?? ()
legacy/trac#200 0x6962732f in ?? ()
legacy/trac#201 0x752f3a6e in ?? ()
legacy/trac#202 0x6c2f7273 in ?? ()
legacy/trac#203 0x6c61636f in ?? ()
legacy/trac#204 0x6e69622f in ?? ()
legacy/trac#205 0x62732f3a in ?? ()
legacy/trac#206 0x2f3a6e69 in ?? ()
legacy/trac#207 0x3a6e6962 in ?? ()
legacy/trac#208 0x7273752f in ?? ()
legacy/trac#209 0x6962732f in ?? ()
legacy/trac#210 0x752f3a6e in ?? ()
legacy/trac#211 0x622f7273 in ?? ()
legacy/trac#212 0x4d006e69 in ?? ()
legacy/trac#213 0x3d4c4941 in ?? ()
legacy/trac#214 0x7261762f in ?? ()
legacy/trac#215 0x69616d2f in ?? ()
legacy/trac#216 0x6f722f6c in ?? ()
legacy/trac#217 0x5000746f in ?? ()
legacy/trac#218 0x2f3d4457 in ?? ()
legacy/trac#219 0x2f726176 in ?? ()
legacy/trac#220 0x2f62696c in ?? ()
legacy/trac#221 0x00726f74 in ?? ()
legacy/trac#222 0x454d4f48 in ?? ()
legacy/trac#223 0x6f722f3d in ?? ()
legacy/trac#224 0x5300746f in ?? ()
legacy/trac#225 0x4c564c48 in ?? ()
legacy/trac#226 0x4c00323d in ?? ()
legacy/trac#227 0x414e474f in ?? ()
legacy/trac#228 0x723d454d in ?? ()
legacy/trac#229 0x00746f6f in ?? ()
legacy/trac#230 0x732f3d5f in ?? ()
legacy/trac#231 0x2f6e6962 in ?? ()
legacy/trac#232 0x72617473 in ?? ()
legacy/trac#233 0x74732d74 in ?? ()
legacy/trac#234 0x642d706f in ?? ()
legacy/trac#235 0x6f6d6561 in ?? ()
legacy/trac#236 0x752f006e in ?? ()
legacy/trac#237 0x732f7273 in ?? ()
legacy/trac#238 0x2f6e6962 in ?? ()
legacy/trac#239 0x00726f74 in ?? ()
legacy/trac#240 0x00000000 in ?? ()
---cut
hope that helps.
cu
Rainer
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: konquiAndrew LewmanAndrew Lewmanhttps://gitlab.torproject.org/tpo/core/tor/-/issues/360Error from libevent: event_queue_remove: 0xfa5260(fd -1) not on queue 12020-06-27T14:10:48ZTracError from libevent: event_queue_remove: 0xfa5260(fd -1) not on queue 1Hi,
the following error message appeared one time in the logfile:
---snip---
Nov 15 11:51:26.681 [err] Error from libevent: event_queue_remove: 0xfa5260(fd -1) not on queue 1
---snap---
System:
Server road2nowhere
OS: SuSE 10.0 64Bit
l...Hi,
the following error message appeared one time in the logfile:
---snip---
Nov 15 11:51:26.681 [err] Error from libevent: event_queue_remove: 0xfa5260(fd -1) not on queue 1
---snap---
System:
Server road2nowhere
OS: SuSE 10.0 64Bit
libevent version: 1.1-2
Openssl version: OpenSSL 0.9.7g 11 Apr 2005
regards,
Joerg
[Automatically added by flyspray2trac: Operating System: Other Linux]
**Trac**:
**Username**: Maschihttps://gitlab.torproject.org/tpo/core/tor/-/issues/361[Error] routerparse.c:647: router_parse_list_from_string: Assertion *s failed...2020-06-27T14:10:48ZTrac[Error] routerparse.c:647: router_parse_list_from_string: Assertion *s failed; abort.encountered the following error on Mac OS X (vers. 10.4.8),
with Vidalia 0.0.9 when trying to launch tor v0.1.2.3-alpha
via the vidalia interface:
[Notice] Tor v0.1.2.3-alpha. This is experimental software. Do not rely on it for strong...encountered the following error on Mac OS X (vers. 10.4.8),
with Vidalia 0.0.9 when trying to launch tor v0.1.2.3-alpha
via the vidalia interface:
[Notice] Tor v0.1.2.3-alpha. This is experimental software. Do not rely on it for strong anonymity.
[Notice] Enabling experimental OS X kqueue support with libevent 1.2. If this turns out to not work, set the environment variable EVENT_NOKQUEUE, and tell the Tor developers.
[Notice] Initialized libevent version 1.2 using method kqueue. Good.
[Notice] Opening Socks listener on 127.0.0.1:9050
[Notice] Opening Control listener on 127.0.0.1:9051
[Error] routerparse.c:647: router_parse_list_from_string: Assertion *s failed; aborting.
repeatable: yes
occurence: always since first time
consequence: tor does not start
I had no log file, so I can not tell what happened the first time before the crash.
I am sorry if this bug should have been discovered before, I did not find it.
Greetings, simplicity.
[Automatically added by flyspray2trac: Operating System: OSX 10.4 Tiger]
**Trac**:
**Username**: simplicityhttps://gitlab.torproject.org/tpo/core/tor/-/issues/362Tor crashes after numerous failed name resolutions.2020-06-27T14:10:48ZTracTor crashes after numerous failed name resolutions.If a tor exit node is unable to contact a DNS server, after numerous failed name resolution
attempts, tor will crash.
gdb(1) seems to always point to the FreeBSD pthread library when asking "where" post-mortem.
Apologies for not having ...If a tor exit node is unable to contact a DNS server, after numerous failed name resolution
attempts, tor will crash.
gdb(1) seems to always point to the FreeBSD pthread library when asking "where" post-mortem.
Apologies for not having the exact output, as I have fixed the issue and no longer have the
core (and would like to not break it again).
However, should you be confirming this, the easiest way to replicate this is by setting up a
tor exit node with a relatively unrestricted exit policy (the default should do). Make sure
that tor does *not* query a valid nameserver by modifying your /etc/resolv.conf (easiest way
to do this without breaking DNS on the host machine is to run tor in a chroot(8) or jail(8)
environment) to point to an invalid nameserver. After a few hours (maybe less on high band-
width nodes) tor will crash, dropping it's core.
[Automatically added by flyspray2trac: Operating System: BSD]
**Trac**:
**Username**: Orumhttps://gitlab.torproject.org/tpo/core/tor/-/issues/363Refuse to start if /etc/resolv.conf cannot be read/parsed2020-06-27T14:10:48ZTracRefuse to start if /etc/resolv.conf cannot be read/parsedTor exit nodes currently assume a local nameserver listening on 127.0.0.1 if /etc/resolv.conf
cannot be found (or parsed, I would assume). However, in order to mitigate DNS issues with exit
nodes (i.e. those described in task legacy/tra...Tor exit nodes currently assume a local nameserver listening on 127.0.0.1 if /etc/resolv.conf
cannot be found (or parsed, I would assume). However, in order to mitigate DNS issues with exit
nodes (i.e. those described in task legacy/trac#362), I think tor should refuse to start (or at least log a
warning/error to stderr) if this is the case. Of course, this does not solve all DNS issues, as
invalid DNS servers could still easily exist in /etc/resolv.conf, but it will at least act as a
basic "dummy proofing" for those chrooting/jailing their tor exit nodes.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: Orum0.1.2.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/364DNS lookup problems2020-06-27T14:10:48ZTracDNS lookup problemsI am still, even with 1.1.25, getting DNS resolutions like:
stbmac:/Library/Tor Michael$ tor-resolve en.wikipedia.org
127.0.0.1
There doesn't seem to be any way to find out which host is supplying these
bad references (so that they ca...I am still, even with 1.1.25, getting DNS resolutions like:
stbmac:/Library/Tor Michael$ tor-resolve en.wikipedia.org
127.0.0.1
There doesn't seem to be any way to find out which host is supplying these
bad references (so that they can be added to ExcludeHosts), nor does there
seem to be any sort of double checking on DNS data returned.
Normal DNS relies on being able to trust the roots, and then eventually being
able to trust the systems that they claim are reliable, to track down
authoritative answers. Tor's resolution seems to ignore that -- anyone's
answer is accepted.
To make matters worse, even after turning off tor, Firefox (1.8) still
caches the output page from Privoxy that claims that the address cannot
be resolved, and trying to reload returns the same page. (I know, that
one's not your department.)
Current configuration:
All requests go through privoxy.
Privoxy's config has lines:
# Tor:
##
## forward-socks4a / localhost:9050 .
forward-socks4a .onion localhost:9050 .
# Do not torrify these (high volume/speed concerns):
forward .vidalia-project.net .
forward 127.0.0.1 .
That first line (with the "## ") is toggled to turn tor on/off. When turned on,
I still get complaints about 127.0.0.1 and the "reloading server list /
determining server location" function of vidalia still takes forever and
occasionally logs in the console.
[Automatically added by flyspray2trac: Operating System: All]
**Trac**:
**Username**: keybounce0.1.2.x-finalNick MathewsonNick Mathewson