Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2020-06-13T13:58:57Zhttps://gitlab.torproject.org/legacy/trac/-/issues/549massive memory leak in exit nodes2020-06-13T13:58:57ZRoger Dingledinemassive memory leak in exit nodesmikeperry ran 0.1.2.17 on his exit node under valgrind:
==1715== 141,696 bytes in 492 blocks are possibly lost in loss record 15 of 17
==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==1715== by 0x80B7240: _tor_malloc (uti...mikeperry ran 0.1.2.17 on his exit node under valgrind:
==1715== 141,696 bytes in 492 blocks are possibly lost in loss record 15 of 17
==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==1715== by 0x80B7240: _tor_malloc (util.c:116)
==1715== by 0x80B8F06: _tor_malloc_zero (util.c:135)
==1715== by 0x808AB2A: dns_resolve (dns.c:719)
==1715== by 0x8071513: connection_exit_begin_conn (connection_edge.c:2250)
==1715== by 0x8095BA3: connection_edge_process_relay_cell (relay.c:1023)
==1715== by 0x8096310: circuit_receive_relay_cell (relay.c:171)
==1715== by 0x805B96E: command_process_cell (command.c:327)
==1715== by 0x80732BC: connection_or_process_inbuf (connection_or.c:768)
==1715== by 0x8067954: connection_process_inbuf (connection.c:2238)
==1715== by 0x806A792: connection_handle_read (connection.c:1449)
==1715== by 0x8091107: conn_read_callback (main.c:422)
==1715==
==1715==
==1715== 178,968,672 (177,808,896 direct, 1,159,776 indirect) bytes in 617,392 blocks are definitely lost in loss record 17 of 17
==1715== at 0x40053C0: malloc (vg_replace_malloc.c:149)
==1715== by 0x80B7240: _tor_malloc (util.c:116)
==1715== by 0x80B8F06: _tor_malloc_zero (util.c:135)
==1715== by 0x808AB2A: dns_resolve (dns.c:719)
==1715== by 0x8071513: connection_exit_begin_conn (connection_edge.c:2250)
==1715== by 0x8095BA3: connection_edge_process_relay_cell (relay.c:1023)
==1715== by 0x8096310: circuit_receive_relay_cell (relay.c:171)
==1715== by 0x805B96E: command_process_cell (command.c:327)
==1715== by 0x80732BC: connection_or_process_inbuf (connection_or.c:768)
==1715== by 0x8067954: connection_process_inbuf (connection.c:2238)
==1715== by 0x806A792: connection_handle_read (connection.c:1449)
==1715== by 0x8091107: conn_read_callback (main.c:422)
That's this malloc in dns.c:
/* not there, need to add it */
resolve = tor_malloc_zero(sizeof(cached_resolve_t));
resolve->magic = CACHED_RESOLVE_MAGIC;
My first thought is that the "if" above that can still have resolve there,
just without the expected 'expired' value. We should convert r12469 into an
assert at some point.
On closer inspection, r12470 looks like a better candidate for the problem.
[Automatically added by flyspray2trac: Operating System: All]https://gitlab.torproject.org/legacy/trac/-/issues/531Transition from 0.0.0.0 listener to specific listener disallowed2020-06-13T13:58:49ZNick MathewsonTransition from 0.0.0.0 listener to specific listener disallowedCoderman reported back in August that if you try to change from a listener on 0.0.0.0 to a listener on a specific
address, Tor will often fail, because it doesn't close the old listener until the new listener is open (in order
to be undo...Coderman reported back in August that if you try to change from a listener on 0.0.0.0 to a listener on a specific
address, Tor will often fail, because it doesn't close the old listener until the new listener is open (in order
to be undoable), but it can't open the new listener until the old one is closed.
See or-talk/or-dev thread, "Server node stalls on unsuccessful socks listener change."
It looks like we have two options:
1) Disallow the 0.0.0.0 -> non 0.0.0.0 change.
2) When transitioning from 0.0.0.0, accept that the transition will not be perfectly undoable.
[Automatically added by flyspray2trac: Operating System: All]Tor: unspecifiedhttps://gitlab.torproject.org/legacy/trac/-/issues/526Eventdns.c crash after closing and reopening ORPort2020-06-13T13:58:45ZNick MathewsonEventdns.c crash after closing and reopening ORPort[Originally reported by Mike Gersten; moving here so I don't forget about it.]
See or-dev thread from September-October titled "Tor crash", especially:
http://archives.seul.org/or/dev/Sep-2007/msg00031.html (initial post)
http://a...[Originally reported by Mike Gersten; moving here so I don't forget about it.]
See or-dev thread from September-October titled "Tor crash", especially:
http://archives.seul.org/or/dev/Sep-2007/msg00031.html (initial post)
http://archives.seul.org/or/dev/Sep-2007/msg00040.html (stack trace)
The circumstances were:
"I first shut down the Or-port, to try to let all connections close.
When it was time to actually say "Time to stop", I re-enabled the
Or-port, and then sent a sigint. (If I send sigint without first
re-enabling the or-port, Tor assumes that it should stop immediately,
without notifying the clients).
Tor crashed about a minute later. I don't know if it was related or not.
This is 1.2.17."
The stack trace was:
0 tor 0x00087c04 event_del + 44 (event.c:697)
1 tor 0x0006cdd4 nameserver_up + 84 (eventdns.c:533)
2 tor 0x0006cee0 reply_callback + 112 (eventdns.c:648)
3 tor 0x0006fc6c reply_handle + 684 (eventdns.c:740)
4 tor 0x000714cc nameserver_ready_callback + 1564
(eventdns.c:925)
5 tor 0x00087364 event_process_active + 240 (event.c:332)
6 tor 0x00087634 event_base_loop + 340 (event.c:448)
7 tor 0x000874cc event_loop + 40 (event.c:382)
8 tor 0x000873d0 event_dispatch + 20 (event.c:346)
9 tor 0x0004b8b0 tor_main + 656 (main.c:1270)
10 tor 0x0000277c _start + 760
11 tor 0x00002480 start + 48
[Automatically added by flyspray2trac: Operating System: All]0.2.1.x-finalNick MathewsonNick Mathewson