Running a relay under valgrind: ``` ==46685== 37,152 (288 direct, 36,864 indirect) bytes in 18 blocks are definitely lost in loss record 76 of 81 ==46685== at 0x4A06A2E: malloc (vg_replace_malloc.c:270) ==46685== by 0x295047: tor_malloc_ (util.c:150) ==46685== by 0x28691E: smartlist_new (container.c:34) ==46685== by 0x223173: store_multiple (consdiffmgr.c:1150) ==46685== by 0x22351C: consensus_compress_worker_replyfn (consdiffmgr.c:1714) ==46685== by 0x29B871: replyqueue_process (workqueue.c:634) ==46685== by 0x2F28D3: event_persist_closure (in /home/tord2/tor/src/or/tor) ==46685== by 0x2F2BE4: event_process_active_single_queue (in /home/tord2/tor/src/or/tor) ==46685== by 0x2F325F: event_process_active (in /home/tord2/tor/src/or/tor) ==46685== by 0x2F39C3: event_base_loop (in /home/tord2/tor/src/or/tor) ==46685== by 0x155CAC: do_main_loop (main.c:2607) ==46685== by 0x156DEC: tor_main (main.c:3756) ``` Sure enough, `consdiffmgr_ensure_space_for_files()` looks like it has a ``` smartlist_t *objects = smartlist_new(); ``` and `objects` is never freed in this function. Looks like the bug arrived in commit 7a096427. This said, that's a lot of indirect lost bytes too. Is there something *in* the smartlist that gets leaked too? I didn't find anything obvious.