Trac issueshttps://gitlab.torproject.org/legacy/trac/-/issues2022-10-17T19:28:07Zhttps://gitlab.torproject.org/legacy/trac/-/issues/19969tor client does not immediately open new circuits after standby2022-10-17T19:28:07Zweasel (Peter Palfrader)tor client does not immediately open new circuits after standbyViktor writes via https://bugs.debian.org/835119:
I use tor only as a client to connect icedove to the tor network with
the extension Torbirdy (on port 9050). With the tor version 0.2.8.6 I
can't immediately connect to any mail server o...Viktor writes via https://bugs.debian.org/835119:
I use tor only as a client to connect icedove to the tor network with
the extension Torbirdy (on port 9050). With the tor version 0.2.8.6 I
can't immediately connect to any mail server or news feed after the pc
woke up from standby ("long" time in standby) and I started icedove. I
have to wait for several minutes in order to connect successfully, but
the timespan seems to be random. This does not occur after a (re)boot.
The first version I remember to have this issue is 0.2.8.6-2, I did an
upgrade from 0.2.7.6-1 to 0.2.8.6-2, so I skipped the alpha and rc
versions and the first upload to unstable. I am very sure that the issue
didn't occur in version 0.2.7.6-1 which I used for several months. I can
exclude network connectivity problems because e.g. I can immediately
start the Tor Browser after standby.
Today I purged tor, installed version 0.2.7.6-1, copied the old "state"
file to /var/lib/tor, and set the pc in standby mode for a couple of
minutes. After waking up from standby I immediately tried to connect to
a mail server which worked. Then I upgraded step by step to every
version of tor 0.2.8 which I could find on snapshot.debian.org and tried
to connect to a mail server immediately after waking up from standby.
Unfortunately I could not reproduce the bug then. Finally with version
0.2.8.6-3 the bug occured again, but only after a "long" standby time
(almost 90 minutes).
Attached are two log files from the weekend and the complete log from
today after the installation of version 0.2.7.6-1.
As you can see, the bug is not easily reproducible, and the logs don't
show any particular reason for why tor does not open new circuits
immediately. Please tell me what I can do to give you more information
about the bug.Tor: 0.2.8.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24902Denial of Service mitigation subsystem2022-03-17T19:41:32ZDavid Gouletdgoulet@torproject.orgDenial of Service mitigation subsystemThis ticket is for adding a denial of service mitigation subsystem to tor.
Because of the latest issues we've been having on the network with 1 million users most likely resulting in the huge loads on the relays we've been seeing, this ...This ticket is for adding a denial of service mitigation subsystem to tor.
Because of the latest issues we've been having on the network with 1 million users most likely resulting in the huge loads on the relays we've been seeing, this subsystem is to provide a framework in order to add defense to tor for potential (voluntary or not) denial of service.Tor: 0.3.3.x-finalDavid Gouletdgoulet@torproject.orgDavid Gouletdgoulet@torproject.orghttps://gitlab.torproject.org/legacy/trac/-/issues/21394connection timeouts are affecting Tor Browser usability2020-12-21T14:22:51ZArthur Edelsteinconnection timeouts are affecting Tor Browser usabilityI have spent some time watching circuit and stream events while connecting to different sites. I telnet into tor's config port using the following command (using ts to give time stamps):
```
telnet localhost 9151 | ts
```
I open the brow...I have spent some time watching circuit and stream events while connecting to different sites. I telnet into tor's config port using the following command (using ts to give time stamps):
```
telnet localhost 9151 | ts
```
I open the browser console and get the tor password by entering
`m_tb_control_pass`
And then I paste the result like this:
`authenticate [value of m_tb_control_pass]`
Finally I enter
`setevents circ stream`.
What I have noticed is that a significant fraction of new site connections result in at least 1 timeout of 10 seconds. (Tor Browser's CircuitStreamTimeout is set to 0, which results in a timeout equal to MIN_CIRCUIT_STREAM_TIMEOUT, or 10 seconds.) Here's what a timeout looks like:
```
Feb 03 19:00:03 650 STREAM 868 NEW 0 people.torproject.org:443 SOURCE_ADDR=127.0.0.1:50318 PURPOSE=USER
Feb 03 19:00:03 650 CIRC 149 LAUNCHED BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597
Feb 03 19:00:03 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 EXTENDED [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 CIRC 149 BUILT [...] BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:03.738597 SOCKS_USERNAME="torproject.org" SOCKS_PASSWORD="7d8ea4ccf4ba6345846e0fccacd4d941"
Feb 03 19:00:04 650 STREAM 868 SENTCONNECT 149 people.torproject.org:443
[...]
Feb 03 19:00:14 650 STREAM 868 DETACHED 149 people.torproject.org:443 REASON=TIMEOUT
Feb 03 19:00:14 650 CIRC 150 LAUNCHED BUILD_FLAGS=NEED_CAPACITY PURPOSE=GENERAL TIME_CREATED=2017-02-04T03:00:14.588714
```
After a timeout occurs, the tor client closes the circuit, builds a new circuit and attempts to connect to the same site again. This repeats at least 3 times.
I did an experiment where I connected to https://people.torproject.org/~arthuredelstein (a page with hardly any content) and then repeatedly selected "New Tor Circuit for this Site" 50 times.
Here are the results for 50 reloads. Each digit represents the number of 10-second stream timeouts observed before a given connection succeeded.
20020000000000000000002010000000000001000100000103
In other words 8 out of 50 connections showed a timeout. And interestingly, four of these connections exhibited a double or triple timeout (20 or 30 seconds delay).
I think this may be a big part of the perception of Tor Browser as "slow". Actual loading of pages doesn't seem drastically slow to me, and once I have successfully connected to a new site, following links to other pages on the same site (i.e., the same circuit) is usually acceptable.
(I also did another quick test on another site and 5/25 connections had at least 1 timeout.)
So here are some questions for further investigation:
* Why are there so many timeouts? Are any of these timeouts due to silent errors in a Tor node? (If such errors could be promptly reported back to the client, maybe we could avoid the waiting for the long timeout.)
* What's the reason for MIN_CIRCUIT_STREAM_TIMEOUT being 10 seconds? Would it do any harm to make this shorter, say 5 seconds or 2 seconds?
* So many double or triple timeouts are suspicious, because each timeout in a double or triple is reported for a different circuit. Could this mean the connection error is caused by the client or guard rather than a connection failure at the exit node?Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24786Rebuild the fallback list in 20182020-06-13T16:21:09ZteorRebuild the fallback list in 2018We need to rebuild the list of fallbacks in late 2018 or early 2019.
We usually do this when 25% or more go down.
(This is tracked in #tor-bots on IRC.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projec...We need to rebuild the list of fallbacks in late 2018 or early 2019.
We usually do this when 25% or more go down.
(This is tracked in #tor-bots on IRC.)
Here are the instructions for running a rebuild:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: 0.4.0.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30184release-0.2.9 doesn't compile on old rhel2020-06-13T16:15:53ZRoger Dingledinerelease-0.2.9 doesn't compile on old rhelOn rhel6, building release-0.2.9 (git commit ca008906), I get
```
CC src/or/src_or_libtor_testing_a-rephist.o
src/or/rephist.c:91: error: redefinition of typedef ‘bw_array_t’
src/or/rephist.h:120: note: previous declaration of ‘bw_...On rhel6, building release-0.2.9 (git commit ca008906), I get
```
CC src/or/src_or_libtor_testing_a-rephist.o
src/or/rephist.c:91: error: redefinition of typedef ‘bw_array_t’
src/or/rephist.h:120: note: previous declaration of ‘bw_array_t’ was here
make[1]: *** [src/or/src_or_libtor_testing_a-rephist.o] Error 1
```
Looks like when we backported some stuff, we didn't backport all of the subsequent fixes on the stuff.
Here is a fix that lets it compile again (there could for sure be a better fix than this):
```
index dc86fad..d8f7eb2 100644
--- a/src/or/rephist.c
+++ b/src/or/rephist.c
@@ -88,7 +88,6 @@
static void bw_arrays_init(void);
static void predicted_ports_init(void);
-typedef struct bw_array_t bw_array_t;
STATIC uint64_t find_largest_max(bw_array_t *b);
STATIC void commit_max(bw_array_t *b);
STATIC void advance_obs(bw_array_t *b);
diff --git a/src/or/rephist.h b/src/or/rephist.h
index c464b34..072987f 100644
--- a/src/or/rephist.h
+++ b/src/or/rephist.h
@@ -114,10 +114,10 @@ void rep_hist_log_link_protocol_counts(void);
extern uint64_t rephist_total_alloc;
extern uint32_t rephist_total_num;
+typedef struct bw_array_t bw_array_t;
#ifdef TOR_UNIT_TESTS
extern int onion_handshakes_requested[MAX_ONION_HANDSHAKE_TYPE+1];
extern int onion_handshakes_assigned[MAX_ONION_HANDSHAKE_TYPE+1];
-typedef struct bw_array_t bw_array_t;
extern bw_array_t *write_array;
#endif
```
(My bwauth still runs on 0.2.9, since I'm under the impression that's the last version that works well with bwauths. That's how I noticed.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/24801Generate a new fallback list and backport it2020-06-13T16:06:24ZteorGenerate a new fallback list and backport itI can generate a new list over the weekend.
This will be easier once all the other children of #22271 merge.I can generate a new list over the weekend.
This will be easier once all the other children of #22271 merge.Tor: 0.3.2.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/21564Regenerate fallback list for 0.3.1 or 0.3.22020-06-13T16:06:01ZteorRegenerate fallback list for 0.3.1 or 0.3.2This involves:
* checking for new relays
* contacting potential fallback operators
* rebuilding the list
* contacting all fallback operators
See detailed instructions here:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallb...This involves:
* checking for new relays
* contacting potential fallback operators
* rebuilding the list
* contacting all fallback operators
See detailed instructions here:
https://trac.torproject.org/projects/tor/wiki/doc/UpdatingFallbackDirectoryMirrorsTor: 0.3.1.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/20170Backport latest fallback list to 0.2.8 and 0.2.92020-06-13T16:05:43ZteorBackport latest fallback list to 0.2.8 and 0.2.9I'm generating a new list of fallback directory mirrors for release 0.2.9 in #18828.
We have a few options for dealing with the 0.2.8 list:
* comment-out any broken fallbacks,
* backport the 0.2.9 list,
* do nothing.
I would prefer to ...I'm generating a new list of fallback directory mirrors for release 0.2.9 in #18828.
We have a few options for dealing with the 0.2.8 list:
* comment-out any broken fallbacks,
* backport the 0.2.9 list,
* do nothing.
I would prefer to have the same src/or/fallback_dirs.inc in every (relevant) Tor release, assuming we do another 0.2.8 series release.
This is consistent with how we handle directory authorities and geoip.
Otherwise it becomes hard to check multiple fallback lists at once.
But I could be convinced to go with either of the other options.Tor: 0.2.8.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/28574Appveyor: OpenSSL unit test fails with header and library version mismatch2020-06-13T15:52:21ZteorAppveyor: OpenSSL unit test fails with header and library version mismatchI'm guessing that 1.1.1a and 1.1.1 are compatible, though?
```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:238: OpenSSL library version 1.1.1 did not begin with header version 1.1.1a.
[openssl_version FAILED]
``...I'm guessing that 1.1.1a and 1.1.1 are compatible, though?
```
crypto/openssl_version: [forking]
FAIL ../src/test/test_crypto.c:238: OpenSSL library version 1.1.1 did not begin with header version 1.1.1a.
[openssl_version FAILED]
```
https://ci.appveyor.com/project/torproject/tor/build/1.0.1625/job/gibgc64fp4hxsf2h?fullLog=true#L3064Tor: 0.3.4.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/32629Re-enable 1 or 2 more macOS jobs in Travis2020-06-13T15:48:43ZteorRe-enable 1 or 2 more macOS jobs in TravisReverts #32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Reverts #32177.
We might need to merge or disable some jobs, to get builds to finish fast enough.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32500consider clang -std=gnu99 in Travis for better C99 portability2020-06-13T15:48:15ZTaylor Yuconsider clang -std=gnu99 in Travis for better C99 portabilityIn #32495, we discovered that `-Wtypedef-redefinition` doesn't seem to work on clang unless `-std=gnu99` or similar is used. (typedef redefinitions are apparently allowed in C11) It does seem to work on FreeBSD's cc for some reason, but ...In #32495, we discovered that `-Wtypedef-redefinition` doesn't seem to work on clang unless `-std=gnu99` or similar is used. (typedef redefinitions are apparently allowed in C11) It does seem to work on FreeBSD's cc for some reason, but we don't use FreeBSD in Travis.
We should consider using something like `-std=gnu99` in our Travis configuration for clang, so we can catch additional instances of this sort of portability problem earlier.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32260Backport "Travis: Use Ubuntu Bionic, but keep Trusty for chutney"2020-06-13T15:47:26ZteorBackport "Travis: Use Ubuntu Bionic, but keep Trusty for chutney"We should keep the build images consistent across releases.We should keep the build images consistent across releases.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32241Travis: Use a newer macOS image2020-06-13T15:47:22ZteorTravis: Use a newer macOS imageI tried some newer images, here's what I found:
Xcode 10.1:
* https://github.com/teor2345/tor/tree/macos_image_10_1
* build took longer than 50 minutes
Xcode 10.3:
* https://github.com/teor2345/tor/tree/macos_image_10_3
* build took 19...I tried some newer images, here's what I found:
Xcode 10.1:
* https://github.com/teor2345/tor/tree/macos_image_10_1
* build took longer than 50 minutes
Xcode 10.3:
* https://github.com/teor2345/tor/tree/macos_image_10_3
* build took 19 minutes, vs 9 minutes for the current image
Xcode 11.2:
* https://github.com/teor2345/tor/tree/macos_image_11_2
* build took 12 minutes, vs 9 minutes for the current image
Let's revisit in a few months.
We could try older images, and see if they are faster. But I don't think macOS is limiting our builds right now.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/32240Tor Travis: Make chutney work on Xenial and Bionic images2020-06-13T15:47:22ZteorTor Travis: Make chutney work on Xenial and Bionic imagesWe get weird permissions errors like this:
```
FAIL: basic-min
Detail: chutney/tools/warnings.sh /home/travis/build/teor2345/tor/chutney/net/nodes.1571845015
Warning: Can't create/check datadirectory /home/travis/build/teor2345/tor/chutn...We get weird permissions errors like this:
```
FAIL: basic-min
Detail: chutney/tools/warnings.sh /home/travis/build/teor2345/tor/chutney/net/nodes.1571845015
Warning: Can't create/check datadirectory /home/travis/build/teor2345/tor/chutney/net/nodes/002r Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/000a/key-pinning-journal" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/001a/key-pinning-journal" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-certs": Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-consensus" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-descriptors" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-extrainfo" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-microdesc-consensus" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-microdescs" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/cached-microdescs.new": Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/unverified-consensus" for mmap(): Permission denied Number: 1
Warning: Could not open "/home/travis/build/teor2345/tor/chutney/net/nodes/003c/unverified-microdesc-consensus" for mmap(): Permission denied Number: 1
Warning: Directory /home/travis/build/teor2345/tor/chutney/net/nodes/002r cannot be read: Permission denied Number: 1
Warning: Error initializing keys; exiting Number: 1
Warning: Error loading key-pinning journal: Permission denied Number: 2
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/30860Add a chutney job that runs on macOS, so that IPv6 chutney tests work2020-06-13T15:46:04ZteorAdd a chutney job that runs on macOS, so that IPv6 chutney tests workTravis Linux doesn't support IPv6, so we should add a macOS chutney job to Tor's CI.
If that's too slow, we can:
* add the chutney tests to the end of an existing macOS job
* change the chutney job to macOS
Remember: each build has a l...Travis Linux doesn't support IPv6, so we should add a macOS chutney job to Tor's CI.
If that's too slow, we can:
* add the chutney tests to the end of an existing macOS job
* change the chutney job to macOS
Remember: each build has a limit of 2 concurrent macOS jobs.
We can do this task after #29280 merges.Tor: 0.2.9.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31673Deprecated use of <sys/sysctl.h>2020-06-13T15:45:23ZDavid Gouletdgoulet@torproject.orgDeprecated use of <sys/sysctl.h>I've been getting warnings since couple days ago:
```
/usr/include/x86_64-linux-gnu/sys/sysctl.h:21:2: warning: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Wcpp]
21 | #warning "The <sys/sysctl.h> header ...I've been getting warnings since couple days ago:
```
/usr/include/x86_64-linux-gnu/sys/sysctl.h:21:2: warning: #warning "The <sys/sysctl.h> header is deprecated and will be removed." [-Wcpp]
21 | #warning "The <sys/sysctl.h> header is deprecated and will be removed."
```
It is annoying with `enable-gcc-warnings` since it errors.
I've removed that include and tor builds fine so, as nickm suggested on IRC, right solution here is to not include on Linux/Win32 instead of `#ifdef HAVE_SYS_SYSCTL_H`.
I would recommend a backport since if this becomes a problem to build tor in the future.Tor: 0.4.1.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/31406new ip-address for tor.dizum.com (auth-dir)2020-06-13T15:44:16ZAlex de Joodenew ip-address for tor.dizum.com (auth-dir)```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Guys,
tor.dizum.com has changed it's IP address. As tor.dizum.com is a directory server, it's ip address is hardcoded in the source code.
Please update the ip.
OLD: 194.109.206.212...```
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Guys,
tor.dizum.com has changed it's IP address. As tor.dizum.com is a directory server, it's ip address is hardcoded in the source code.
Please update the ip.
OLD: 194.109.206.212
NEW: 45.66.33.45
You can verify and validate this change by either
1) retrieving the ip for tor.dizum.com.
2) contact alex, by email or by phone or on irc to verify this change.
3) you could read the announcement at the dir-auth list.
-----BEGIN PGP SIGNATURE-----
Version: BCPG v1.47
iGYEARECACYFAl1RuckfHEFsZXggZGUgSm9vZGUgPGFsZXhAaWRnYXJhLm5sPgAK
CRB4AD5zEX0r0DQsAJwN+/zRHTRgIiiXps8Lw0NieQgFpACgoz/YHdlt/X2YMQQL
bpY/OwGavRE=
=SFAn
-----END PGP SIGNATURE-----
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/legacy/trac/-/issues/27465Windows: cast between incompatible function types in address.c2020-06-13T15:44:11ZteorWindows: cast between incompatible function types in address.c```
bash.exe : ../src/common/address.c: In function 'get_interface_addresses_win32':
At line:2 char:5
+ & $commandPath $args 2>&1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (../src/common/a...dresses_...```
bash.exe : ../src/common/address.c: In function 'get_interface_addresses_win32':
At line:2 char:5
+ & $commandPath $args 2>&1
+ ~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (../src/common/a...dresses_win32'::String) [], RemoteException
+ FullyQualifiedErrorId : NativeCommandError
../src/common/address.c:1499:14: error: cast between incompatible function types from 'FARPROC' {aka 'long long int (*)()'} to 'ULONG (*)(ULONG, ULONG, void *, IP_ADAPTER_ADDRESSES_XP *, ULONG *)' {aka 'long unsigned int
(*)(long unsigned int, long unsigned int, void *, struct _IP_ADAPTER_ADDRESSES_XP *, long unsigned int *)'} [-Werror=cast-function-type]
if (!(fn = (GetAdaptersAddresses_fn_t)
^
```
https://ci.appveyor.com/project/teor2345/tor/build/1.0.152/job/g7dxnnck0r3p66n9#L1093Tor: 0.3.4.x-finalteorteorhttps://gitlab.torproject.org/legacy/trac/-/issues/31374Appveyor: cast between incompatible function types in compat_time2020-06-13T15:44:11ZteorAppveyor: 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 #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/legacy/trac/-/issues/31372Appveyor and Travis should use "make -k"2020-06-13T15:44:10ZNick MathewsonAppveyor and Travis should use "make -k"Right now our .appveyor.yml and .travis.yml are not using the "-k" make flag. That means that once it encounters an error, it stops building. In general, we would prefer our CI to keep trying to build for a long as it can, so that we c...Right now our .appveyor.yml and .travis.yml are not using the "-k" make flag. That means that once it encounters an error, it stops building. In general, we would prefer our CI to keep trying to build for a long as it can, so that we can see all of the warnings and errors that are produced. This will help us save round trips between the developer and the CI process.Tor: 0.4.1.x-finalNick MathewsonNick Mathewson