Skip to content

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.

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information