Tor issueshttps://gitlab.torproject.org/tpo/core/tor/-/issues2020-06-27T14:06:22Zhttps://gitlab.torproject.org/tpo/core/tor/-/issues/5861MSVC/win32: IPPROTO_IPV6 only defined when _WIN32_WINNT >= 0x05012020-06-27T14:06:22ZNick MathewsonMSVC/win32: IPPROTO_IPV6 only defined when _WIN32_WINNT >= 0x0501When we're providing IPv6 support, we need to setsockopt(IPPROTO_IPV6, IPPROTO_IPV6ONLY) on our listeners so that they bind the address we want them to bind.
But with the MS-provided ws2def.h I've got, IPPROTO_IPV6 is only declared when...When we're providing IPv6 support, we need to setsockopt(IPPROTO_IPV6, IPPROTO_IPV6ONLY) on our listeners so that they bind the address we want them to bind.
But with the MS-provided ws2def.h I've got, IPPROTO_IPV6 is only declared when _WIN32_WINNT >= 0x0501 (that is, when we say we want to build for XP or higher).
The easiest fix here would be to just drop support for pre-XP windowses and set _WIN32_WINNT to 0x0501. The next-easiest fix would be to hard-define IPPROTO_IPV6 to 41 when building for windows.
Marking this as "major" because it blocks building with MSVC.Tor: 0.2.3.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7305enum variables with defined bit width2020-06-27T14:05:22ZTracenum variables with defined bit widthThe signedness of an enum type according to the C standard is implementation-defined, and thus shouldn't be relied on. However, the code implicitly assumes it's unsigned (a gcc-specific thing?), and uses constructs like this:
```
typedef...The signedness of an enum type according to the C standard is implementation-defined, and thus shouldn't be relied on. However, the code implicitly assumes it's unsigned (a gcc-specific thing?), and uses constructs like this:
```
typedef enum {
ADDR_POLICY_ACCEPT=1,
ADDR_POLICY_REJECT=2,
} addr_policy_action_t;
addr_policy_action_t policy_type:2;
```
What happens to the above case with the MSVC compiler is that it treats the enum type as signed, and writing a '2' makes two's-complement math kick in, so '2' becomes '-2'. One unit test fails because of this, which is how I noticed it. The consequence is that Tor's state can easily destabilize, and impossible execution paths like this could occur:
```
test = 2;
assert( test == 2 ); // triggers
```
There are workarounds, like wrapping the enum in a struct (very ugly), or using an integer type for storage (loss of type info). Ideally stop using bit packing entirely in memory-only structures, and serialize to integer types of exact size when crafting packets (an enum's size is variable in gcc, fixed in msvc).
Here's a list of all offending places for patterns ":N" and ": N", N=1..9:
* circ_id_type_t circ_id_type:2;
* addr_policy_action_t policy_type:2;
* path_state_t path_state : 2;
* addressmap_entry_source_t [3;](3;)
* } state : 3;
* } dir_spool_src : 3;
* saved_location_t saved_location : 3;
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7308libevent used uninitialized on faulty code path2020-06-27T14:05:22ZTraclibevent used uninitialized on faulty code path`[warn] warning from libevent: event_add: event has no event_base set.`
The modern libevent provides reentrant functions (base* parameter), but it still exposes the old interface and deprecated global state variables. Tor's tor_libevent...`[warn] warning from libevent: event_add: event has no event_base set.`
The modern libevent provides reentrant functions (base* parameter), but it still exposes the old interface and deprecated global state variables. Tor's tor_libevent_initialize() decides to use the new interface, and completely skips the old event_init() call which would initialize the global state.
In src/ocmmon/compat_libevent.h, the function tor_event_base_loopexit() is #ifdefed based on a configure variable called HAVE_EVENT_BASE_LOOPEXIT. If it's defined, it forwards to libevent, otherwise it expands to a helper function. This function calls one of the old interfaces that rely on global state.
The bug is that current src/win32/orconfig.h defines HAVE_EVENT2_EVENT_H but does not define HAVE_EVENT_BASE_LOOPEXIT. This causes the abovementioned code to skip initializing the old global libevent state, but then later ends up calling a function that depends on it.
Adding #define HAVE_EVENT_BASE_LOOPEXIT to orconfig.h fixes it.
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7309nmake script wrong main build target output filename2020-06-27T14:05:22ZTracnmake script wrong main build target output filenameIn src/or/Makefile.nmake build target "tor.exe", the commandline does not include an output filename parameter. MSVC's cl.exe does a strange thing and guesses the output filename based on the last thing on the list, which in this case is...In src/or/Makefile.nmake build target "tor.exe", the commandline does not include an output filename parameter. MSVC's cl.exe does a strange thing and guesses the output filename based on the last thing on the list, which in this case is tor_main.obj. This means that the build output is tor_main.exe, not tor.exe.
To specify an output filename, add /Fe followed by the filename - without a space inbetween - somewhere into the commandline. In this case it would be /Fetor.exe.
PS: According to google search nmake supports the standard make token for 'rule target', implying that /Fe$@ (for compiler) and /out$@ (for linker) could work and might be useful in a future cleanup.
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7310nmake script LIBS variable uses .a instead of .lib2020-06-27T14:05:22ZTracnmake script LIBS variable uses .a instead of .libIn src/or/Makefile.nmake the LIBS variable refernces third-party libraries libevent.a, libcrypto.a, libssl.a and libz.a. This file extension confuses the MSVC linker, which will print warnings about unknown type and "assuming". Using the...In src/or/Makefile.nmake the LIBS variable refernces third-party libraries libevent.a, libcrypto.a, libssl.a and libz.a. This file extension confuses the MSVC linker, which will print warnings about unknown type and "assuming". Using the .lib file extension is more appropriate since this is what the linked projects use. Curiously enough, src/test/Makefile.nmake already has this 'fix', so I'm not sure what happened there.
PS: there's a naming inconsistency: libcrypto -> libeay32, libssl -> ssleay32, libz -> zlib
these are easily worked around using symlinks, but it makes me wonder if openssl has a toggle for the legacy/defunct eay product imitation.
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7311nmake scripts missing platform dependencies for openssl2020-06-27T14:05:21ZTracnmake scripts missing platform dependencies for opensslAll nmake scripts that link to openssl (all of them) are reporting missing platform dependencies. At least for openssl 1.0.1c, the following are also required:
* crypt32.lib <- openssl's e_capi.c ms crypto functions
* gdi32.lib <- open...All nmake scripts that link to openssl (all of them) are reporting missing platform dependencies. At least for openssl 1.0.1c, the following are also required:
* crypt32.lib <- openssl's e_capi.c ms crypto functions
* gdi32.lib <- openssl's readscreen(), seeds RNG with screen bitmap
* user32.lib <- openssl's isservice() check and showfatal() MessageBox
Maybe openssl added these features since the makefiles were first added?
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7312nmake scripts missing include ../ext path2020-06-27T14:05:21ZTracnmake scripts missing include ../ext pathAll 0.2.4+ nmake makefiles need to be updated to match the change that split off external code to the ../ext directory. In particular, since all of them are used in the main codebase via #include "..." directives, ext needs to be in the ...All 0.2.4+ nmake makefiles need to be updated to match the change that split off external code to the ../ext directory. In particular, since all of them are used in the main codebase via #include "..." directives, ext needs to be in the include path.
The fix is easy, just append
`/I ..\ext`
to every CFLAGS.
PS: an even cleaner way would be to split off an INCLUDES variable to hold the include paths. Maybe even use some $() magic to tack on the /I part after-the-fact.
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7313msvc compilation error for libevent2, missing HAVE_EVENT2_DNS_H2020-06-27T14:05:21ZTracmsvc compilation error for libevent2, missing HAVE_EVENT2_DNS_HIf we assume MSVC builds have to use the latest available libevent version (no reason not to since it has to be built from source anyway), then src/win32/orconfig.h requires an additional line:
```
#define HAVE_EVENT2_DNS_H
```
otherwise...If we assume MSVC builds have to use the latest available libevent version (no reason not to since it has to be built from source anyway), then src/win32/orconfig.h requires an additional line:
```
#define HAVE_EVENT2_DNS_H
```
otherwise mixing of old and new version code happens, and
```
3>libtor.lib(dns.obj) : error LNK2019: unresolved external symbol _evdns_set_default_outgoing_bind_address referenced in function _configure_nameservers
3>libtor.lib(dns.obj) : error LNK2019: unresolved external symbol _evtimer_add referenced in function _dns_launch_correctness_checks
3>libtor.lib(dns.obj) : error LNK2019: unresolved external symbol _evtimer_new referenced in function _dns_launch_correctness_checks
```
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7315nmake script outdated list of source files2020-06-27T14:05:21ZTracnmake script outdated list of source filessrc/or/Makefile.nmake is out of sync with 0.2.3.x, and even more out of sync with 0.2.4.x.
Missing LIBTOR_OBJECTS in 0.2.3:
```
transports.obj
```
Missing LIBTOR_OBJECTS in 0.2.4/master:
```
circuitstats.obj
confparse.obj
entrynodes.ob...src/or/Makefile.nmake is out of sync with 0.2.3.x, and even more out of sync with 0.2.4.x.
Missing LIBTOR_OBJECTS in 0.2.3:
```
transports.obj
```
Missing LIBTOR_OBJECTS in 0.2.4/master:
```
circuitstats.obj
confparse.obj
entrynodes.obj
replaycache.obj
routerset.obj
statefile.obj
transports.obj
```
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7316nmake script for tests missing build targets2020-06-27T14:05:21ZTracnmake script for tests missing build targetssrc/test/Makefile.nmake only builds test.exe and omits test-child.exe (required part of test.exe unit tests) and bench.exe (a set of benchmarks). The following patch fixes that:
```
diff --git a/src/test/Makefile.nmake b/src/test/Makefil...src/test/Makefile.nmake only builds test.exe and omits test-child.exe (required part of test.exe unit tests) and bench.exe (a set of benchmarks). The following patch fixes that:
```
diff --git a/src/test/Makefile.nmake b/src/test/Makefile.nmake
index aec477c..8ab077a 100644
--- a/src/test/Makefile.nmake
+++ b/src/test/Makefile.nmake
@@ -1,4 +1,4 @@
-all: test.exe
+all: test.exe test-child.exe bench.exe
CFLAGS = /I ..\win32 /I ..\..\..\build-alpha\include /I ..\common /I ..\or
@@ -16,5 +16,11 @@ TEST_OBJECTS = test.obj test_addr.obj test_containers.obj \
test.exe: $(TEST_OBJECTS)
$(CC) $(CFLAGS) $(LIBS) ..\common\*.lib $(TEST_OBJECTS)
+test-child.exe: test-child.obj
+ $(CC) test-child.obj
+
+bench.exe: bench.obj
+ $(CC) bench.obj $(LIBS) ..\common\*.lib
+
clean:
del $(TEST_OBJECTS) *.lib test.exe
```
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7669SIZEOF_INTPTR_T not defined in msvc builds2020-06-27T14:05:08ZTracSIZEOF_INTPTR_T not defined in msvc buildsChange [1bfda600](https://gitweb.torproject.org/tor.git/commit/1bfda600) added a block of helper code to src/common/compat.h that assumes SIZEOF_INTPTR_T is defined. While this is the case for configure-driven builds (defines available s...Change [1bfda600](https://gitweb.torproject.org/tor.git/commit/1bfda600) added a block of helper code to src/common/compat.h that assumes SIZEOF_INTPTR_T is defined. While this is the case for configure-driven builds (defines available since [2004](https://gitweb.torproject.org/tor.git/commit/8aebd83a)), for the prepared win32 config the define is nowhere to be found. This causes a compilation error.
I looked and saw that torint.h introduces type intptr_t when HAVE_INTPTR_T is not present. Also, it does `#if (SIZEOF_INTPTR_T != 0) #define HAVE_INTPTR_T`, so just defining it in orconfig.h would actually break this code. My first guess is that torint.h should define the sizeof at the moment it adds the intptr_t typedef. There might be better solutions.
PS: uintptr_t should be dealt with as well.
**Trac**:
**Username**: ultramageTor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/7754Fix build and correctness issues with MSVC2020-06-27T14:05:05ZNick MathewsonFix build and correctness issues with MSVCThis is a parent ticket for various MSVC issues that ultramage has been finding and reporting.This is a parent ticket for various MSVC issues that ultramage has been finding and reporting.Tor: 0.2.4.x-finalhttps://gitlab.torproject.org/tpo/core/tor/-/issues/13081Fix build with Visual Studio in Windows2020-07-24T16:04:33ZTracFix build with Visual Studio in WindowsI have attached a patch to fix the missing objects during compilation.
The build process itself will have to be better documented in the future.
**Trac**:
**Username**: NewEraCrackerI have attached a patch to fix the missing objects during compilation.
The build process itself will have to be better documented in the future.
**Trac**:
**Username**: NewEraCrackerTor: unspecifiedhttps://gitlab.torproject.org/tpo/core/tor/-/issues/16030Visual Studio 2013 Test Problems2020-06-27T14:01:13ZTracVisual Studio 2013 Test ProblemsI've built Tor using the patch tor-0.2.6.7-msvs2013-build.diff (29/04/2015 20:18:15) posted at legacy/trac#13081 with mingw32 and MSVC2013.
Build with mingw32 goes fine. Tests go fine.
Build with MSVC2013 goes "fine" with some warning...I've built Tor using the patch tor-0.2.6.7-msvs2013-build.diff (29/04/2015 20:18:15) posted at legacy/trac#13081 with mingw32 and MSVC2013.
Build with mingw32 goes fine. Tests go fine.
Build with MSVC2013 goes "fine" with some warnings in both Release and Test configuration. There are 10 test failures. The fail of util/logging/sigsafe_err is expected as it was failing on 0.2.5.12 with MSVC2010 as far as I remember. The other 9 failures are quite bad as they result in crashes.
Attached are some build logs.
**Trac**:
**Username**: NewEraCrackerhttps://gitlab.torproject.org/tpo/core/tor/-/issues/18716MEMAREA_ALIGN_MASK is wrong for MSVC on x642020-06-27T13:59:18ZTracMEMAREA_ALIGN_MASK is wrong for MSVC on x64#define MEMAREA_ALIGN_MASK 7lu
change to:
#define MEMAREA_ALIGN_MASK 7llu
otherwise assert is thrown here:
memarea.c:128: tor_assert(realign_pointer(res->next_mem) == res->next_mem);
**Trac**:
**Username**: wbenny#define MEMAREA_ALIGN_MASK 7lu
change to:
#define MEMAREA_ALIGN_MASK 7llu
otherwise assert is thrown here:
memarea.c:128: tor_assert(realign_pointer(res->next_mem) == res->next_mem);
**Trac**:
**Username**: wbennyTor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/24633to->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。2020-06-27T13:54:40ZTracto->pending->tqh_last is 0xFFFFFFFFFFFFFFFF。I'm debuging tor. And it throw an error at function timeouts_sched,
The version is: release-0.3.2
this is the stack:
> tor.exe!timeouts_sched(timeouts * T=0x0000000000517e90, timeout * to=0x0000000003307450, unsigned __int64 expires=21...I'm debuging tor. And it throw an error at function timeouts_sched,
The version is: release-0.3.2
this is the stack:
> tor.exe!timeouts_sched(timeouts * T=0x0000000000517e90, timeout * to=0x0000000003307450, unsigned __int64 expires=2123027) 行 355 C
tor.exe!timeouts_add(timeouts * T=0x0000000000517e90, timeout * to=0x0000000003307450, unsigned __int64 timeout=6290) 行 394 C
tor.exe!timer_schedule(timeout * t=0x0000000003307450, const timeval * tv=0x000000000027dee8) 行 300 C
tor.exe!channelpadding_schedule_padding(channel_s * chan=0x00000000032f7c80, int in_ms=629) 行 478 C
tor.exe!channelpadding_decide_to_pad_channel(channel_s * chan=0x00000000032f7c80) 行 783 C
tor.exe!run_connection_housekeeping(int i=3, __int64 now=1513329560) 行 1132 C
tor.exe!run_scheduled_events(__int64 now=1513329560) 行 1464 C
tor.exe!second_elapsed_callback(periodic_timer_t * timer=0x00000000042a5550, void * arg=0x0000000000000000) 行 2216 C
tor.exe!periodic_timer_cb(__int64 fd=-1, short what=1, void * arg=0x00000000042a5550) 行 187 C
tor.exe!event_persist_closure(event_base * base=0x00000000004e8fa0, event * ev=0x000000000427d200) 行 1532 C
tor.exe!event_process_active_single_queue(event_base * base=0x00000000004e8fa0, evcallback_list * activeq=0x00000000004e8eb0, int max_to_process=2147483647, const timeval * endtime=0x0000000000000000) 行 1591 C
tor.exe!event_process_active(event_base * base=0x00000000004e8fa0) 行 1689 C
tor.exe!event_base_loop(event_base * base=0x00000000004e8fa0, int flags=0) 行 1912 C
tor.exe!run_main_loop_once() 行 2631 C
tor.exe!run_main_loop_until_done() 行 2685 C
tor.exe!do_main_loop() 行 2599 C
tor.exe!tor_main(int argc=1, char * * argv=0x000000000046c850) 行 3780 C
tor.exe!main(int argc=1, char * * argv=0x000000000046c850) 行 34 C
1.Run tor
2.when it say Bootstrapped 100%: Done, disable network
3.enable network
It will crush.
timeout.c
#if !defined WHEEL_NUM
#define WHEEL_NUM 4
#endif
...
struct timeouts {
struct timeout_list wheel[WHEEL_NUM][WHEEL_LEN], expired;
...
}
In function timeouts_sched,
int wheel, slot;
...
wheel = timeout_wheel(rem);
...
to->pending = &T->wheel[wheel][slot];
if wheel >= WHEEL_NUM, it will crush.
**Trac**:
**Username**: sx5486510Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/40773Tor fails to build with MSVC2023-06-26T13:43:57Zgabi-250Tor fails to build with MSVCReported by Gisle Vanem on tor-dev@ https://lists.torproject.org/pipermail/tor-dev/2023-March/014825.html:
```
Trying to compile Tor with 'cl' ver. 19.36.32323 from
yesterdays 'git master', I got this error in
'src/feature/hs/hs_metrics_...Reported by Gisle Vanem on tor-dev@ https://lists.torproject.org/pipermail/tor-dev/2023-March/014825.html:
```
Trying to compile Tor with 'cl' ver. 19.36.32323 from
yesterdays 'git master', I got this error in
'src/feature/hs/hs_metrics_entry.c':
hs/hs_metrics_entry.c(98,3): error C2099: initializer is not a constant
{
^
hs/hs_metrics_entry.c(106,3): error C2099: initializer is not a constant
{
^
----------
This MSVC compiler is rather stupid; it fails to parse that
'static const size_t hs_metrics_circ_build_time_buckets_size'
is truly 'const'. No problem with 'clang-cl'.
But this patch works:
--- a/feature/hs/hs_metrics_entry.c 2023-03-17 18:00:57
+++ b/feature/hs/hs_metrics_entry.c 2023-03-18 13:56:58
@@ -28,8 +28,7 @@
60000 /* 60s */
};
-static const size_t hs_metrics_circ_build_time_buckets_size =
- ARRAY_LENGTH(hs_metrics_circ_build_time_buckets);
+#define hs_metrics_circ_build_time_buckets_size ARRAY_LENGTH(hs_metrics_circ_build_time_buckets)
-----------------
```gabi-250gabi-250