Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2023-08-28T12:28:35Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40822[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED s...2023-08-28T12:28:35ZTimeIsGold[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED section was seen 0 seconds ago. Dropping cell.I am running HS using Tor 0.4.7.13 Running on Windows Server and i am using Obfs4 Bridges for my nodes.
i got this messages every day and i don't know what is the problem
`[warn] Possible replay detected! An INTRODUCE2 cell with the sam...I am running HS using Tor 0.4.7.13 Running on Windows Server and i am using Obfs4 Bridges for my nodes.
i got this messages every day and i don't know what is the problem
`[warn] Possible replay detected! An INTRODUCE2 cell with the same ENCRYPTED section was seen 0 seconds ago. Dropping cell.`
`[notice] Your network connection speed appears to have changed. Resetting timeout to 60000ms after 18 timeouts and 1000 buildtimes.`https://gitlab.torproject.org/tpo/core/tor/-/issues/40678Crash on Windows after DNSPort request2024-01-08T13:31:05ZcypherpunksCrash on Windows after DNSPort requestTor 4.7.7, on Windows, crashes after receiving the following request on DNSPort.
`000201000001000000000000076578616d706c6503636f6d0000010001`
Full pcap:
<pre>
1MOyoQIABAAAAAAAAAAAAAAABAAAAAAAIq6cYnvfCQAiAAAAIgAAAAIAAABFAAAe
hk0AAIARAAB/...Tor 4.7.7, on Windows, crashes after receiving the following request on DNSPort.
`000201000001000000000000076578616d706c6503636f6d0000010001`
Full pcap:
<pre>
1MOyoQIABAAAAAAAAAAAAAAABAAAAAAAIq6cYnvfCQAiAAAAIgAAAAIAAABFAAAe
hk0AAIARAAB/AAABfwAAAfLIADYACg68AB0irpxiFeAJAD0AAAA9AAAAAgAAAEUA
ADmGTgAAgBEAAH8AAAF/AAAB8sgANgAlPzMAAgEAAAEAAAAAAAAHZXhhbXBsZQNj
b20AAAEAAQ==
</pre>Tor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40669Win10x64 - tor.exe not starting anymore at all when using GeoIPFile or GeoIPv...2022-08-30T20:18:51ZtpgrrWin10x64 - tor.exe not starting anymore at all when using GeoIPFile or GeoIPv6FileIn an (AFAIK) unchanged Tor installation¹ (torbrowser-install-win64-11.0.6_en-US.exe) tor.exe ceases to start since 2022/04/28.
Last successful start: 2022/04/20 (not tried in between), no log file is written whatsoever (despite "Log not...In an (AFAIK) unchanged Tor installation¹ (torbrowser-install-win64-11.0.6_en-US.exe) tor.exe ceases to start since 2022/04/28.
Last successful start: 2022/04/20 (not tried in between), no log file is written whatsoever (despite "Log notice file ..." in torrc) when failing.
Tracing the issue down I reduced torrc to only these 4 lines:
> Log notice file R:\Temp\Tor.log
> DataDirectory C:\Tools\Tor\Data\
> GeoIPFile C:\Tools\Tor\Data\geoip
> GeoIPv6File C:\Tools\Tor\Data\geoip6
I found that _disabling_ GeoIP functionality allows tor.exe to start again.
> #GeoIPFile C:\Tools\Tor\Data\geoip
> #GeoIPv6File C:\Tools\Tor\Data\geoip6
As soon as I enable either one (or both) of the GeoIP DBs tor just crashes without a trace.
Same with Tor extracted from latest version²
System:
Win10x64 Version 10.0.19043.1288, no AV except MS Defender 4.18.2203.5-0
¹ Windows unchanged as well - all updates are manual, no other admins
² extracted from torbrowser-install-win64-11.0.10_de.exe\Browser\TorBrowser\ and [...]\Browser\Data\ (using 7-zip)
P.S. Sorry for odd the line spacing, I may be too dumb for this editorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40631Confidential: From cypherpunks: DNSPort crash on Windows2023-05-25T13:16:36ZNick MathewsonConfidential: From cypherpunks: DNSPort crash on WindowsWe've received this apport on anonticket. Out of caution, I'm sticking it in a confidential ticket manually, since it *might* be some kind of memory safety issue.
> Tor 4.7.7, on Windows, crashes after receiving the following request o...We've received this apport on anonticket. Out of caution, I'm sticking it in a confidential ticket manually, since it *might* be some kind of memory safety issue.
> Tor 4.7.7, on Windows, crashes after receiving the following request on DNSPort. `000201000001000000000000076578616d706c6503636f6d0000010001` Full pcap:
>
> <pre> 1MOyoQIABAAAAAAAAAAAAAAABAAAAAAAIq6cYnvfCQAiAAAAIgAAAAIAAABFAAAe hk0AAIARAAB/AAABfwAAAfLIADYACg68AB0irpxiFeAJAD0AAAA9AAAAAgAAAEUA ADmGTgAAgBEAAH8AAAF/AAAB8sgANgAlPzMAAgEAAAEAAAAAAAAHZXhhbXBsZQNj b20AAAEAAQ==</pre>
Let's see what's up here.
cc @dgoulet @ahfTor: 0.4.8.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40596Bug: Non-fatal assertion failed in process_win32_read_from_handle2022-11-01T13:16:09ZcypherpunksBug: Non-fatal assertion failed in process_win32_read_from_handleOn win32, latest Tor 0.4.6.10
when starting with torrc consisting of:
<code>ClientTransportPlugin trebuchet exec /path/to/snowflake-client.exe
Bridge trebuchet 127.0.0.1:123</code>
Logs the following:
```
Jan 1 00:00:00.000 [notice] B...On win32, latest Tor 0.4.6.10
when starting with torrc consisting of:
<code>ClientTransportPlugin trebuchet exec /path/to/snowflake-client.exe
Bridge trebuchet 127.0.0.1:123</code>
Logs the following:
```
Jan 1 00:00:00.000 [notice] Bootstrapped 0% (starting): Starting
Jan 1 00:00:00.000 [notice] Starting with guard context "default"
Jan 1 00:00:00.000 [warn] Client managed proxy encountered a method error. (trebuchet no such method)
Jan 1 00:00:00.000 [warn] Managed proxy at '/path/to/snowflake-client.exe' failed the configuration protocol and will be destroyed.
Jan 1 00:00:00.000 [warn] tor_bug_occurred_(): Bug: process_win32.c:891: process_win32_read_from_handle: Non-fatal assertion !(handle->reached_eof) failed. (on Tor 0.4.6.10 22fd351cf582aa2b)
Jan 1 00:00:00.000 [warn] Bug: Tor 0.4.6.10 (git-22fd351cf582aa2b): Non-fatal assertion !(handle->reached_eof) failed in process_win32_read_from_handle at process_win32.c:891. (Stack trace not available) (on Tor 0.4.6.10 22fd351cf582aa2b)
Jan 1 00:00:00.000 [warn] Pluggable Transport process terminated with status code 0
Jan 1 00:00:00.000 [notice] Bootstrapped 5% (conn): Connecting to a relay
```
Interestingly, bug doesn't happen if I put obfs4proxy instead of snowflake-client, so something additional triggers it in Snowflake (version from latest TBB). But I think tor mustn't log Bug's no matter how broken PT is.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40341Windows 32-bit build broken with introduction of `overload_happened_recently(...2022-07-07T00:47:10ZAlexander Færøyahf@torproject.orgWindows 32-bit build broken with introduction of `overload_happened_recently()` in rephist.cCommit 0a5ecb334298187a64f58382231245111130aa76 introduced a new function named `overload_happened_recently()` which does a comparison between signed and unsigned data on 32-bit Windows.
The error is:
```
src/feature/stats/rephist.c: I...Commit 0a5ecb334298187a64f58382231245111130aa76 introduced a new function named `overload_happened_recently()` which does a comparison between signed and unsigned data on 32-bit Windows.
The error is:
```
src/feature/stats/rephist.c: In function ‘overload_happened_recently’:
src/feature/stats/rephist.c:215:21: error: comparison between signed and unsigned integer expressions [-Werror=sign-compare]
if (overload_time > approx_time() - 3600 * n_hours) {
```
See: https://travis-ci.org/github/ahf/tor-win32/jobs/763284597#L8775-L8777Tor: 0.4.6.x-stableGeorge KadianakisGeorge Kadianakishttps://gitlab.torproject.org/tpo/core/tor/-/issues/40294Detect the need for and enable '__USE_MINGW_ANSI_STDIO=0' in configure2021-10-19T12:29:39ZAlexander Færøyahf@torproject.orgDetect the need for and enable '__USE_MINGW_ANSI_STDIO=0' in configureCurrently when building Tor on Windows with a modern MinGW-based toolchain, it is necessary to have `CFLAGS='-D__USE_MINGW_ANSI_STDIO=0'"` defined. We should detect this in `configure` and enable it if needed automatically.
In commit d9...Currently when building Tor on Windows with a modern MinGW-based toolchain, it is necessary to have `CFLAGS='-D__USE_MINGW_ANSI_STDIO=0'"` defined. We should detect this in `configure` and enable it if needed automatically.
In commit d9cc2b2928eab045f89d0abf95a9e5c75e290ff8, this was enabled for our AppVeyor builds by explicitly setting the definition in the `CFLAGS` variable.
An example of the error that happens when this is not set:
```
In file included from ./src/lib/crypt_ops/crypto_rsa.h:21,
from ./src/core/or/or.h:31,
from src/core/mainloop/connection.c:58:
src/core/mainloop/connection.c: In function ‘connection_free_minimal’:
src/core/mainloop/connection.c:875:16: error: unknown conversion type character ‘l’ in format [-Werror=format=]
875 | "Freeing orconn at %p, saw channel %p with ID "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:875:16: error: too many arguments for format [-Werror=format-extra-args]
875 | "Freeing orconn at %p, saw channel %p with ID "
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_close_immediate’:
src/core/mainloop/connection.c:1056:21: error: unknown conversion type character ‘l’ in format [-Werror=format=]
1056 | log_info(LD_NET,"fd %d, type %s, state %s, %"TOR_PRIuSZ" bytes on outbuf.",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:1056:21: error: too many arguments for format [-Werror=format-extra-args]
1056 | log_info(LD_NET,"fd %d, type %s, state %s, %"TOR_PRIuSZ" bytes on outbuf.",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:274:43: note: in definition of macro ‘log_info’
274 | log_fn_(LOG_INFO, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_connect_sockaddr’:
src/core/mainloop/connection.c:2242:10: error: unknown conversion type character ‘l’ in format [-Werror=format=]
2242 | "Connection to socket %s (sock "TOR_SOCKET_T_FORMAT").",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:284:43: note: in definition of macro ‘log_fn’
284 | log_fn_(severity, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c:2242:10: error: too many arguments for format [-Werror=format-extra-args]
2242 | "Connection to socket %s (sock "TOR_SOCKET_T_FORMAT").",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
./src/lib/log/log.h:284:43: note: in definition of macro ‘log_fn’
284 | log_fn_(severity, domain, __FUNCTION__, args, ##__VA_ARGS__)
| ^~~~
src/core/mainloop/connection.c: In function ‘connection_dump_buffer_mem_stats’:
src/core/mainloop/connection.c:5552:6: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5552:6: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5552:6: error: too many arguments for format [-Werror=format-extra-args]
5552 | "In buffers for %d connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/core/mainloop/connection.c:5559:9: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5559:9: error: unknown conversion type character ‘l’ in format [-Werror=format=]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ./src/lib/cc/compat_compiler.h:16,
from ./src/core/or/or.h:26,
from src/core/mainloop/connection.c:58:
/usr/share/mingw-w64/include/inttypes.h:36:18: note: format string is defined here
36 | #define PRIu64 "llu"
| ^
src/core/mainloop/connection.c:5559:9: error: too many arguments for format [-Werror=format-extra-args]
5559 | " For %d %s connections: %"PRIu64" used/%"PRIu64" allocated",
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:12417: src/core/mainloop/connection.o] Error 1
make[2]: Leaving directory '/home/ahf/src/github.com/ahf/tor-win32/src/tor'
make[1]: *** [Makefile:7346: all] Error 2
make[1]: Leaving directory '/home/ahf/src/github.com/ahf/tor-win32/src/tor'
make: *** [Makefile:81: tor] Error 2
```Tor: 0.4.7.x-freezeAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40199Nightly Windows build failures on both 32-bit and 64-bit2021-02-05T21:03:36ZAlexander Færøyahf@torproject.orgNightly Windows build failures on both 32-bit and 64-bitOur current Windows nightly builds fails for two different reasons right now:
```src/feature/stats/rephist.c: In function ‘rep_hist_format_hs_stats’:
src/feature/stats/rephist.c:2012:34: error: format ‘%ld’ expects argument of type ‘lon...Our current Windows nightly builds fails for two different reasons right now:
```src/feature/stats/rephist.c: In function ‘rep_hist_format_hs_stats’:
src/feature/stats/rephist.c:2012:34: error: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘time_t {aka long long int}’ [-Werror=format=]
tor_asprintf(&hs_stats_string, "%s %s (%ld s)\n"
```
and
```
src/test/test_stats.c: In function ‘test_rephist_v3_onions’:
src/test/test_stats.c:527:22: error: overflow in implicit constant conversion [-Werror=overflow]
update_approx_time(10101010101);
```
Patch coming up.Alexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/40116Tor ./configure fails when --enable-static-libevent and --enable-static-opens...2020-11-18T16:31:02ZrichardTor ./configure fails when --enable-static-libevent and --enable-static-openssl when cross compiling mingw targetSome of the test programs fail to build due to missing symbols provided by bcrypt.dll and iphlpapi.dll which are normally resolved when building libevent.dll
Possible fix:
```
diff --git a/configure.ac b/configure.ac
index 2e1de76606....Some of the test programs fail to build due to missing symbols provided by bcrypt.dll and iphlpapi.dll which are normally resolved when building libevent.dll
Possible fix:
```
diff --git a/configure.ac b/configure.ac
index 2e1de76606..82bc320a9e 100644
--- a/configure.ac
+++ b/configure.ac
@@ -871,6 +871,7 @@ if test "$bwin32" = "true"; then
# think it's actually necessary.
TOR_LIB_GDI=-lgdi32
TOR_LIB_USERENV=-luserenv
+ TOR_LIB_BCRYPT=-lbcrypt
else
TOR_LIB_WS32=
TOR_LIB_GDI=
@@ -879,6 +880,7 @@ fi
AC_SUBST(TOR_LIB_WS32)
AC_SUBST(TOR_LIB_GDI)
AC_SUBST(TOR_LIB_IPHLPAPI)
+AC_SUBST(TOR_LIB_BCRYPT)
AC_SUBST(TOR_LIB_SHLWAPI)
AC_SUBST(TOR_LIB_USERENV)
@@ -896,7 +898,7 @@ if test "$enable_static_libevent" = "yes"; then
fi
fi
-TOR_SEARCH_LIBRARY(libevent, $trylibeventdir, [-levent $STATIC_LIBEVENT_FLAGS $TOR_LIB_WS32], [
+TOR_SEARCH_LIBRARY(libevent, $trylibeventdir, [-levent $STATIC_LIBEVENT_FLAGS $TOR_LIB_IPHLPAPI $TOR_LIB_BCRYPT $TOR_LIB_WS32], [
#ifdef _WIN32
#include <winsock2.h>
#endif
```
EDIT: see patch that fixes openssl linker problems as well -> https://gitlab.torproject.org/tpo/core/tor/-/issues/40116#note_2707945Tor: 0.4.5.x-stableDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/34211Add support for control signals (ex. Ctrl+C) in Windows2020-07-28T18:48:06ZTracAdd support for control signals (ex. Ctrl+C) in WindowsHi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the on...Hi everyone!
I am working on a [cross-platform Tor controller/wrapper](https://github.com/DcodingTheWeb/ProxAllium/tree/next-gen), and I encountered a minor inconvenience while writing code for stopping Tor in Windows.
Currently the only way to gracefully terminate Tor in Windows is to use the control port to issue the `SIGINT` signal, it would be beneficial for 3rd party programs which work with Tor to be able to invoke this procedure by using the native "control signals" provided to console programs in Windows.
I have made a patch which implements this functionality, I will post it soon, I am creating this ticket so that I can create a corresponding file in the `changes` directory :)
Thanks to nickm for some pointers about using the libevent `event_active` function to trigger the event, I decided to use the `activate_signal` function as it internally calls the suggested function and simplifies the code.
**Trac**:
**Username**: TheDcoderTor: 0.4.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33768Make tor_inet_pton() handle bad addresses consistently on Windows2020-07-09T17:42:27ZteorMake tor_inet_pton() handle bad addresses consistently on Windowstor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/p...tor_inet_pton() handles bad addresses differently on Windows and Linux/macOS.
For example, the address: "2000::1a00::1000:fc098" (two "::") fails this test on Windows, but succeeds on Linux and macOS:
https://github.com/torproject/tor/pull/1831/commits/05f4f93722d46c0e8f1d09b4dea4bf5d1743d93f#diff-048243cd6d9ed36dda0944181d8ec8abR1729
Let's fix this bug and backport it.
In general, we should make all the functions in this file behave identically:
* zero any out parameters at the start of the function
* zero any out parameters on failureTor: 0.4.5.x-freezeDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/33702RSA_get0_d could not be located in the dynamic link library tor.exe2023-05-31T18:44:10ZTracRSA_get0_d could not be located in the dynamic link library tor.exeOS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browse...OS: Win10 (win64)
Tor Browser will not run, when attempting to establish a connection the following error appeats:
The procedure entry point RSA_get0_d could not be located in the dynamic link library C:\Users\MyUser\Desktop\Tor Browser\Browser\TorBrowser\Tor\tor.exe
**Trac**:
**Username**: ner0https://gitlab.torproject.org/tpo/core/tor/-/issues/33673Use the right DLLs and pkg-config path on Appveyor2020-06-27T13:48:00ZteorUse the right DLLs and pkg-config path on AppveyorWe want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from legacy/trac#33643, which is the urgent CI fix.We want to future-proof our Appveyor CI against dll and pkg-config issues.
Split off from legacy/trac#33643, which is the urgent CI fix.Tor: 0.3.5.x-finalteorteorhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33643Appveyor: OpenSSL version mismatch in unit tests, 2020 edition2020-06-27T13:48:02ZteorAppveyor: OpenSSL version mismatch in unit tests, 2020 editionIt's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#285...It's happened again:
```
OpenSSL library version 1.1.1d did not begin with header version 1.1.1e.
```
https://ci.appveyor.com/project/torproject/tor/builds/31549942/job/v0i9svtg78gqln1v#L6380
Just like legacy/trac#32449, legacy/trac#28574, legacy/trac#28399 and legacy/trac#25942.
We think our tests are fragile, because they are not copying the necessary libraries into `${env:build}/src/test` from `C:/mingw32/lib`:
```
ssl
crypto
lzma
event
zstd
```
We already copy zlib and ssp at https://github.com/ahf/tor/blob/master/.appveyor.yml#L98-L99 .
These libraries might have different dll prefixes or suffixes, for example, OpenSSL is:
```
/mingw32/bin/libcrypto-1_1.dll
/mingw32/bin/libssl-1_1.dll
```
https://packages.msys2.org/package/mingw-w64-i686-openssl
We might also want to copy these libraries into the same directory as the tor executable `${env:build}/src/app`, before we run the tests that launch tor.Tor: 0.3.5.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33554Excessive CPU usage in windows tor_cond_t code?2020-07-29T14:37:47ZNick MathewsonExcessive CPU usage in windows tor_cond_t code?On legacy/trac#33411, gvanem reports excdessive CPU consumption in the windows tor_cond_t code. We should see if we can fix that.On legacy/trac#33411, gvanem reports excdessive CPU consumption in the windows tor_cond_t code. We should see if we can fix that.Tor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33469INTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:239: lock_r...2022-06-17T18:06:22ZTracINTERNAL ERROR: Raw assertion failed at src/lib/malloc/map_anon.c:239: lock_result == 0I tried updating to latest stable version and I have this error after a couple of minutes:
```
Feb 27 14:38:04.987 [notice] Tor 0.4.2.6 (git-971a6beff5a53434) running on Windows Server 2003 with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zli...I tried updating to latest stable version and I have this error after a couple of minutes:
```
Feb 27 14:38:04.987 [notice] Tor 0.4.2.6 (git-971a6beff5a53434) running on Windows Server 2003 with Libevent 2.1.8-stable, OpenSSL 1.1.1d, Zlib 1.2.11, Liblzma N/A, and Libzstd N/A.
Feb 27 14:38:05.003 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Feb 27 14:38:05.018 [notice] Read configuration file "U:\2\Server\TOR\tor.ini".
Feb 27 14:38:05.018 [notice] Based on detected system memory, MaxMemInQueues is set to 2048 MB. You can override this by setting MaxMemInQueues by hand.
Feb 27 14:38:05.034 [warn] You specified a public address '0.0.0.0:8080' for SocksPort. Other people on the Internet might find your computer and use it as an open proxy. Please don't allow this unless you have a good reason.
Feb 27 14:38:05.034 [notice] Opening Socks listener on 0.0.0.0:8080
Feb 27 14:38:05.034 [notice] Opened Socks listener on 0.0.0.0:8080
Feb 27 14:38:05.034 [notice] Opening Control listener on 127.0.0.1:9051
Feb 27 14:38:05.049 [notice] Opened Control listener on 127.0.0.1:9051
Feb 27 14:38:05.049 [notice] Opening OR listener on 0.0.0.0:9001
Feb 27 14:38:05.049 [notice] Opened OR listener on 0.0.0.0:9001
Feb 27 14:38:05.049 [notice] Opening Directory listener on 0.0.0.0:9030
Feb 27 14:38:05.049 [notice] Opened Directory listener on 0.0.0.0:9030
============================================================ T= 1582807176
INTERNAL ERROR: Raw assertion failed in Tor 0.4.2.6 (git-971a6beff5a53434) at src/lib/malloc/map_anon.c:239: lock_result == 0
```
**Trac**:
**Username**: m95dhttps://gitlab.torproject.org/tpo/core/tor/-/issues/33411Make DirCache default to 0 on Windows relays, if we can't fix the mmap issues2022-02-28T19:41:25ZteorMake DirCache default to 0 on Windows relays, if we can't fix the mmap issuesIn legacy/trac#24857, tor's consensus diff cache implementation causes high CPU load on Windows.
As a workaround, we could make DirCache default to 0 on Windows.In legacy/trac#24857, tor's consensus diff cache implementation causes high CPU load on Windows.
As a workaround, we could make DirCache default to 0 on Windows.Tor: 0.4.4.x-finalAlexander Færøyahf@torproject.orgAlexander Færøyahf@torproject.orghttps://gitlab.torproject.org/tpo/core/tor/-/issues/31397Appveyor: pacman.exe : error: msys: signature … is invalid2020-06-27T13:49:39ZteorAppveyor: pacman.exe : error: msys: signature … is invalidThe msys signature is invalid, which causes all our Appveyor builds to fail.
This issue first occurred around 0645 UTC Monday 12 August 2019.
It appears to be an external issue.
```
downloading msys.db.sig...
pacman.exe : error: msys: s...The msys signature is invalid, which causes all our Appveyor builds to fail.
This issue first occurred around 0645 UTC Monday 12 August 2019.
It appears to be an external issue.
```
downloading msys.db.sig...
pacman.exe : error: msys: signature from "Alexey Pavlov (Alexpux) <alexpux@gmail.com>" is invalid
At line:2 char:5
+ & $commandPath $args 2>&1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (error: msys: si...om>" is invalid:String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
error:
failed to update msys (invalid or corrupted database (PGP signature))
error: failed to synchronize all databases
Command executed with exception: failed to update msys (invalid or corrupted database (PGP signature))
error: failed to synchronize all databases
```Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31374Appveyor: cast between incompatible function types in compat_time2020-06-27T13:49:40ZteorAppveyor: cast between incompatible function types in compat_timeThe latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | ...The latest Appveyor compiler complains:
{{{
../src/lib/time/compat_time.c:522:25: error: cast between incompatible function types from 'FARPROC' to 'ULONGLONG (__attribute__((stdcall)) *)(void)' [-Werror=cast-function-type]
522 | GetTickCount64_fn = (GetTickCount64_fn_t)
| ^
}}}
This issue is like legacy/trac#27465:
GetProcAddress() returns FARPROC, which is (long long int(*)()) on
64-bit Windows:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms683212(v=vs.85).aspx
But GetTickCount64() is (long long unsigned int(*)()), on both 32-bit
and 64-bit Windows:
https://docs.microsoft.com/en-us/windows/win32/api/sysinfoapi/nf-sysinfoapi-gettickcount64
So gcc 8 issues a spurious "incompatible function pointer" warning
about the cast to GetTickCount64_fn_t.
Silence this warning by casting to a void function pointer, before
the cast to GetTickCount64_fn_t.
Fixes bug NNNNN; bugfix on 0.2.9.1-alpha.Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/31352Jenkins failure on windows: ENETUNREACH undeclared.2020-06-27T13:49:42ZNick MathewsonJenkins failure on windows: ENETUNREACH undeclared.On https://jenkins.torproject.org/job/tor-ci-windows-master/22/consoleFull I see:
```
08:59:23 ../tor/src/test/test_util.c:5402:39: error: 'ENETUNREACH' undeclared (first use in this function)
```
This appears to be new in c46e99c43c4e...On https://jenkins.torproject.org/job/tor-ci-windows-master/22/consoleFull I see:
```
08:59:23 ../tor/src/test/test_util.c:5402:39: error: 'ENETUNREACH' undeclared (first use in this function)
```
This appears to be new in c46e99c43c4ee03, which is not in anything before 0.4.2.Tor: 0.4.2.x-finalNick MathewsonNick Mathewson