Opened 3 years ago
Closed 3 years ago
#21161 closed defect (not a bug)
Invalid free() when a hidden service is configured, to a hostname destination, but we have no network
Reported by: | arma | Owned by: | |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: 0.3.0.x-final |
Component: | Core Tor/Tor | Version: | Tor: 0.3.0.1-alpha |
Severity: | Normal | Keywords: | |
Cc: | weasel | Actual Points: | |
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
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.
Child Tickets
Change History (7)
comment:1 Changed 3 years ago by
comment:2 Changed 3 years ago by
Cc: | weasel added |
---|
comment:3 Changed 3 years ago by
Replying to arma:
It's not clear to me what is going wrong.
See also https://bugzilla.redhat.com/show_bug.cgi?id=754026
comment:4 Changed 3 years ago by
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)
comment:5 Changed 3 years ago by
I'm on some sort of Debian stable like system.
Are you on something different?
Could this be a bug in Debian's glibc?
comment:6 Changed 3 years ago by
noai6ai_cached
makes me think this is a glibc/getaddrinfo bug, and so does https://bugzilla.redhat.com/show_bug.cgi?id=754026
comment:7 Changed 3 years ago by
Resolution: | → not a bug |
---|---|
Status: | new → closed |
Closing this as not-a-bug, since it appears to be an old glibc issue. But please reopen if I am wrong.
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.)