massive memory leak in exit nodes

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]