Tor becomes unresponsive after configuration handling on Windows
When trying to start Tor from master (as of commit `adcd1d8b9ac09f3abc11e2e3187fe363ad3df2fd`), Tor will never progress from the initial configuration handling that is happening before we bootstrap. When starting Tor the following output will appear: ``` PS C:\Users\ahf\AppData\Local\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home\ahf\src\github.com\ahf\tor-win32\src\tor> .\src\or\tor.exe Jul 01 20:58:33.065 [notice] Tor 0.3.5.0-alpha-dev (git-adcd1d8b9ac09f3a) running on Windows 8 with Libevent 2.1.8-stable, OpenSSL 1.0.2n, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A. Jul 01 20:58:33.068 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jul 01 20:58:33.069 [notice] This version is not a stable Tor release. Expect more bugs than usual. Jul 01 20:58:33.084 [notice] Configuration file "C:\Users\ahf\AppData\Roaming\tor\torrc" not present, using reasonable defaults. Jul 01 20:58:33.086 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\Users\ahf\AppData\Local\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home\ahf\src\github.com\ahf\tor-win32\src\tor\<default>. Is this what you wanted? Jul 01 20:58:33.086 [warn] Path for GeoIPv6File (<default>) is relative and will resolve to C:\Users\ahf\AppData\Local\Packages\TheDebianProject.DebianGNULinux_76v4gfsz19hv4\LocalState\rootfs\home\ahf\src\github.com\ahf\tor-win32\src\tor\<default>. Is this what you wanted? ``` After this the process becomes unresponsive. The "Scheduler type KISTLite has been enabled." NOTICE log message is expected here, but is never shown. ### Bisecting the issue I tried to bisect the issue and it looks like the issue began to show up after commit `696f6f15697260255146d634e1529202cc4c2b77` (the commit itself doesn't compile on Windows, but the following couple of commits are related fixes to that patch). The first commit that I can compile where this issue appears is `0b7452eeb2f2dee7acefee2d3ca2cb402a877ea1`. ### Analysis I managed to track the issue down to a call to `strcasecmp()` in `config_lines_eq()` in `src/lib/encoding/confline.c`. I added the following debug output to get a slightly better understanding of what was going on (since gdb wasn't of much help here): ``` diff --git a/src/lib/encoding/confline.c b/src/lib/encoding/confline.c index 7f535b321..4544465d3 100644 --- a/src/lib/encoding/confline.c +++ b/src/lib/encoding/confline.c @@ -14,6 +14,9 @@ #include "lib/string/util_string.h" #include <string.h> +#include <stdio.h> + +#define AHF_DEBUG(...) do { printf(__VA_ARGS__); fflush(stdout); } while (0) /** Helper: allocate a new configuration option mapping 'key' to 'val', * append it to *<b>lst</b>. */ @@ -232,8 +235,26 @@ int config_lines_eq(config_line_t *a, config_line_t *b) { while (a && b) { + AHF_DEBUG("a: %p\n", a); + AHF_DEBUG("b: %p\n", b); + + AHF_DEBUG("a->key: %p\n", a->key); + AHF_DEBUG("a->value: %p\n", a->value); + AHF_DEBUG("a->next: %p\n\n", a->next); + + AHF_DEBUG("b->key: %p\n", b->key); + AHF_DEBUG("b->value: %p\n", b->value); + AHF_DEBUG("b->next: %p\n\n", b->next); + + AHF_DEBUG("a->key: '%s'\n", a->key); + AHF_DEBUG("a->value: '%s'\n", a->value); + + AHF_DEBUG("b->key: '%s'\n", b->key); + AHF_DEBUG("b->value: '%s'\n", b->value); + if (strcasecmp(a->key, b->key) || strcmp(a->value, b->value)) return 0; a = a->next; b = b->next; } ``` Tor would now output the following when started: ``` $ ./src/or/tor.exe Jul 01 21:24:47.029 [notice] Tor 0.3.5.0-alpha-dev (git-0b7452eeb2f2dee7) running on Very recent version of Windows [major=10,minor=0] with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A. Jul 01 21:24:47.029 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jul 01 21:24:47.029 [notice] This version is not a stable Tor release. Expect more bugs than usual. Jul 01 21:24:47.039 [notice] Configuration file "C:\Users\ahf\AppData\Roaming\tor\torrc" not present, using reasonable defaults. Jul 01 21:24:47.041 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\msys64\home\ahf\src\github.com\ahf\tor\<default>. Is this what you wanted? Jul 01 21:24:47.041 [warn] Path for GeoIPv6File (<default>) is relative and will resolve to C:\msys64\home\ahf\src\github.com\ahf\tor\<default>. Is this what you wanted? a: 0000000001C6C9E0 b: 0000000001C6CE60 a->key: 0000000001C6CC50 a->value: 00000000035DAC70 a->next: 0000000000000000 b->key: 0000000001C6CDA0 b->value: 00000000035DACC0 b->next: 0000000000000000 a->key: 'TestingV3AuthInitialVotingInterval' a->value: '1800' b->key: 'TestingV3AuthInitialVotingInterval' b->value: '1800' ``` And after that it would become unresponsive again. If we try to change the call from `strcasecmp()` to `strcmp()` in `config_lines_eq()` Tor will progress and bootstrap successfully: ``` $ ./src/or/tor.exe Jul 01 21:29:19.667 [notice] Tor 0.3.5.0-alpha-dev (git-0b7452eeb2f2dee7) running on Very recent version of Windows [major=10,minor=0] with Libevent 2.1.8-stable, OpenSSL 1.0.2o, Zlib 1.2.11, Liblzma 5.2.4, and Libzstd N/A. Jul 01 21:29:19.667 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning Jul 01 21:29:19.667 [notice] This version is not a stable Tor release. Expect more bugs than usual. Jul 01 21:29:19.678 [notice] Configuration file "C:\Users\ahf\AppData\Roaming\tor\torrc" not present, using reasonable defaults. Jul 01 21:29:19.679 [warn] Path for GeoIPFile (<default>) is relative and will resolve to C:\msys64\home\ahf\src\github.com\ahf\tor\<default>. Is this what you wanted? Jul 01 21:29:19.679 [warn] Path for GeoIPv6File (<default>) is relative and will resolve to C:\msys64\home\ahf\src\github.com\ahf\tor\<default>. Is this what you wanted? a: 000000000139CB30 b: 000000000139C950 a->key: 000000000139C8C0 a->value: 000000000365AF30 a->next: 0000000000000000 b->key: 000000000139C7D0 b->value: 000000000365AF40 b->next: 0000000000000000 a->key: 'TestingV3AuthInitialVotingInterval' a->value: '1800' b->key: 'TestingV3AuthInitialVotingInterval' b->value: '1800' [ ... some debug output omitted here ... ] Jul 01 21:29:19.683 [notice] Scheduler type KISTLite has been enabled. Jul 01 21:29:19.683 [notice] Opening Socks listener on 127.0.0.1:9050 Jul 01 21:29:19.000 [notice] Bootstrapped 0%: Starting Jul 01 21:29:20.000 [notice] Starting with guard context "default" Jul 01 21:29:20.000 [notice] Bootstrapped 80%: Connecting to the Tor network ``` But since our configuration keys are supposed to be case insensitive this is not a fix for the problem. ### Reproducing I have tested this in two different environments: 64-bit Tor compiled via msys2 and 32-bit Tor compiled using my own build scripts from https://github.com/ahf/tor-win32 in a Debian WSL (Windows Subsystem for Linux) container. The results are the same. All of it was done on Windows 10.
issue