prop224: client-side memleaks on the last hidserv request subsystem
I'm getting the following valgrind reports with latest master when trying to connect to prop224 hidden services:
==23490== 24 bytes in 1 blocks are still reachable in loss record 10 of 117
==23490== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==23490== by 0x296577: tor_malloc_ (util.c:150)
==23490== by 0x28F63D: strmap_new (container.c:1428)
==23490== by 0x26A799: get_last_hid_serv_requests (hs_common.c:1369)
==23490== by 0x26A799: hs_clean_last_hid_serv_requests (hs_common.c:1417)
==23490== by 0x26A9F7: hs_pick_hsdir (hs_common.c:1522)
==23490== by 0x2667B6: pick_hsdir_v3 (hs_client.c:157)
==23490== by 0x2667B6: fetch_v3_desc (hs_client.c:173)
==23490== by 0x2667B6: hs_client_refetch_hsdesc (hs_client.c:941)
==23490== by 0x2169E9: connection_ap_handle_onion (connection_edge.c:1558)
==23490== by 0x2169E9: connection_ap_handshake_rewrite_and_attach (connection_edge.c:2020)
==23490== by 0x21807F: connection_ap_process_natd (connection_edge.c:2421)
==23490== by 0x21807F: connection_edge_process_inbuf (connection_edge.c:239)
==23490== by 0x20FED7: connection_handle_read_impl (connection.c:3443)
==23490== by 0x1563D0: conn_read_callback (main.c:736)
==23490== by 0x53613DB: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==23490== by 0x157463: run_main_loop_once (main.c:2627)
==23490== by 0x157463: run_main_loop_until_done (main.c:2681)
==23490== by 0x157463: do_main_loop (main.c:2594)
==23490== 424 bytes in 1 blocks are still reachable in loss record 112 of 117
==23490== at 0x4C28C20: malloc (vg_replace_malloc.c:296)
==23490== by 0x4C2AFCF: realloc (vg_replace_malloc.c:692)
==23490== by 0x296767: tor_realloc_ (util.c:241)
==23490== by 0x28EB2B: strmap_impl_HT_GROW (container.c:1151)
==23490== by 0x28F87A: strmap_set (container.c:1428)
==23490== by 0x26A5F8: hs_lookup_last_hid_serv_request (hs_common.c:1397)
==23490== by 0x26AB0B: hs_pick_hsdir (hs_common.c:1561)
==23490== by 0x2667B6: pick_hsdir_v3 (hs_client.c:157)
==23490== by 0x2667B6: fetch_v3_desc (hs_client.c:173)
==23490== by 0x2667B6: hs_client_refetch_hsdesc (hs_client.c:941)
==23490== by 0x2169E9: connection_ap_handle_onion (connection_edge.c:1558)
==23490== by 0x2169E9: connection_ap_handshake_rewrite_and_attach (connection_edge.c:2020)
==23490== by 0x21807F: connection_ap_process_natd (connection_edge.c:2421)
==23490== by 0x21807F: connection_edge_process_inbuf (connection_edge.c:239)
==23490== by 0x20FED7: connection_handle_read_impl (connection.c:3443)
==23490== by 0x1563D0: conn_read_callback (main.c:736)
==23490==
Probably we are not cleaning that subsystem up sufficiently.