Minor memleak in HSv3 configuration

[asn]

I ran my HSv3 under valgrind for a while. I didn't find anything major.

The only interesting thing I could find is this leaked string during service configuration:

==13380== 26 bytes in 1 blocks are still reachable in loss record 545 of 654
==13380==    at 0x4C2BC20: malloc (vg_replace_malloc.c:296)
==13380==    by 0x2EB977: tor_malloc_ (util_malloc.c:45)
==13380==    by 0x2D6946: esc_for_log (util.c:605)
==13380==    by 0x2D6C3D: escaped (util.c:677)
==13380==    by 0x26D26C: config_generic_service (hs_config.c:372)
==13380==    by 0x26D26C: config_service (hs_config.c:471)
==13380==    by 0x26D26C: hs_config_service_all (hs_config.c:555)
==13380==    by 0x206996: options_validate (config.c:4384)
==13380==    by 0x20AB2F: options_init_from_string (config.c:5497)
==13380==    by 0x20B170: options_init_from_torrc (config.c:5273)
==13380==    by 0x15B7BC: tor_init (main.c:3524)
==13380==    by 0x15C23C: tor_run_main (main.c:4239)
==13380==    by 0x1557A9: tor_main (tor_api.c:84)
==13380==    by 0x155518: main (tor_main.c:32)

[nickm]

This one isn't a true leak -- look at the definition of esc_for_log(). Nonetheless, we should make sure that we actually free it at exit (I thought we did!).

[nickm]

oh wait, I was thinking of escaped(). But that's one we're calling here, so this still probably isn't a real leak. (What escaped() does is to free its last-returned value each time it is called; escaped(NULL) is supposed to free the last-returned value without creating a new one.)

Nonetheless, I am not sure how this is happening. The tor_free_all() function calls escaped(NULL), which is supposed to free this memory.