Invalid free() when a hidden service is configured, to a hostname destination, but we have no network

[arma]

Set up your Tor to offer a hidden service, and use a hostname destination, like localhost:80, on the HiddenServicePort line.

Then ifdown eth0 so you have no network.

Then run valgrind tor --verify-config

and voila, you get this complaint:

Configuration was valid
==31082== Invalid free() / delete / delete[] / realloc()
==31082==    at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==31082==    by 0x63A116B: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==31082==    by 0x4A236CC: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==31082==    by 0x628CAEA: __run_exit_handlers (exit.c:97)
==31082==    by 0x628CB74: exit (exit.c:104)
==31082==    by 0x6276B4B: (below main) (libc-start.c:321)
==31082==  Address 0x65fa2d0 is 0 bytes inside data symbol "noai6ai_cached"

If you leave off the --verify-config, you can trigger the same thing, by starting, and then after a while ctrl-C'ing your Tor so it exits, at which point you get something similar:

==8895== Invalid free() / delete / delete[] / realloc()
==8895==    at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8895==    by 0x63A116B: __libc_freeres (in /lib/x86_64-linux-gnu/libc-2.19.so)
==8895==    by 0x4A236CC: _vgnU_freeres (in /usr/lib/valgrind/vgpreload_core-amd64-linux.so)
==8895==    by 0x628CAEA: __run_exit_handlers (exit.c:97)
==8895==    by 0x628CB74: exit (exit.c:104)
==8895==    by 0x154686: process_signal (main.c:2601)
==8895==    by 0x154686: signal_callback (main.c:2583)
==8895==    by 0x5361A14: event_base_loop (in /usr/lib/x86_64-linux-gnu/libevent-2.0.so.5.1.9)
==8895==    by 0x152B53: run_main_loop_once (main.c:2514)
==8895==    by 0x152B53: run_main_loop_until_done (main.c:2568)
==8895==    by 0x152B53: do_main_loop (main.c:2481)
==8895==    by 0x1562B4: tor_main (main.c:3628)
==8895==    by 0x14E408: main (tor_main.c:34)
==8895==  Address 0x65fa2d0 is 0 bytes inside data symbol "noai6ai_cached"

It's not clear to me what is going wrong.

[arma]

weasel found it in 0.2.5.12, and I confirmed it there, and then confirmed it in master too. (The above traces are from master.)

[arma]

Replying to arma:

It's not clear to me what is going wrong.

See also ​https://bugzilla.redhat.com/show_bug.cgi?id=754026

[asn]

Didn't manage to reproduce this one with the following config:

SocksPort auto
ControlPort auto

HiddenServiceDir /home/user/hidden_service
HiddenServicePort 6667 localhost:6667

and no network interface.

I just get "Configuration was valid" and valgrind finishes fine:

$ valgrind ./src/or/tor -f ../confs/bug21161  --verify-config
==2308== Memcheck, a memory error detector
==2308== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==2308== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==2308== Command: ./src/or/tor -f ../confs/bug21161 --verify-config
==2308== 
Jan 09 14:27:20.019 [notice] Tor 0.3.0.1-alpha-dev (git-655ffeadd53833d9) running on Linux with Libevent 2.0.21-stable, OpenSSL 1.0.1t and Zlib 1.2.8.
Jan 09 14:27:20.060 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Jan 09 14:27:20.061 [notice] This version is not a stable Tor release. Expect more bugs than usual.
Jan 09 14:27:20.073 [notice] Read configuration file "/home/f/Computers/tor/mytor/../confs/bug21161".
Configuration was valid
==2308== 
==2308== HEAP SUMMARY:
==2308==     in use at exit: 73 bytes in 2 blocks
==2308==   total heap usage: 8,654 allocs, 8,652 frees, 512,960 bytes allocated
==2308== 
==2308== LEAK SUMMARY:
==2308==    definitely lost: 28 bytes in 1 blocks
==2308==    indirectly lost: 0 bytes in 0 blocks
==2308==      possibly lost: 0 bytes in 0 blocks
==2308==    still reachable: 45 bytes in 1 blocks
==2308==         suppressed: 0 bytes in 0 blocks
==2308== Rerun with --leak-check=full to see details of leaked memory
==2308== 
==2308== For counts of detected and suppressed errors, rerun with: -v
==2308== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)

[arma]

I'm on some sort of Debian stable like system.

Are you on something different?

Could this be a bug in Debian's glibc?

[nickm]

noai6ai_cached makes me think this is a glibc/getaddrinfo bug, and so does ​https://bugzilla.redhat.com/show_bug.cgi?id=754026

[nickm]

Closing this as not-a-bug, since it appears to be an old glibc issue. But please reopen if I am wrong.