The Tor Project issueshttps://gitlab.torproject.org/groups/tpo/-/issues2020-06-27T14:39:09Zhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19199Allow user to completely disable canvas content and related warning popup fro...2020-06-27T14:39:09ZcypherpunksAllow user to completely disable canvas content and related warning popup from a checkbox in TorButton's "Privacy Settings"Canvas-based fingerprinting is a potent threat to anonymity. I believe it does not make sense to have it potentially enabled (following a popup dialog) at elevated Security Slider settings, and even with the Security Slider on "High," an...Canvas-based fingerprinting is a potent threat to anonymity. I believe it does not make sense to have it potentially enabled (following a popup dialog) at elevated Security Slider settings, and even with the Security Slider on "High," and probably also on Medium-High, Medium, and potentially Medium-Low.
Fingerprintable canvas content (and its related popup) should be completely disabled when the Security Slider is at one of these elevated settings, and it should be transparent to the user. It may make sense to still present the icon in the address bar so that it can be enabled manually, on a per-site or per-page basis, if a user needs this feature.
Thank you all so much.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19197New to Tor. Need help please2021-07-29T06:39:45ZTracNew to Tor. Need help pleaseIt won't establish a connection and I keep getting this log.
28/05/2016 21:29:37.200 [NOTICE] Opening Socks listener on 127.0.0.1:9150
28/05/2016 21:29:37.700 [NOTICE] Bootstrapped 5%: Connecting to directory server
28/05/2016 21:29:3...It won't establish a connection and I keep getting this log.
28/05/2016 21:29:37.200 [NOTICE] Opening Socks listener on 127.0.0.1:9150
28/05/2016 21:29:37.700 [NOTICE] Bootstrapped 5%: Connecting to directory server
28/05/2016 21:29:38.100 [NOTICE] Bootstrapped 10%: Finishing handshake with directory server
28/05/2016 21:30:32.200 [NOTICE] Closing no-longer-configured Socks listener on 127.0.0.1:9150
28/05/2016 21:30:32.200 [NOTICE] DisableNetwork is set. Tor will not make or accept non-control network connections. Shutting down all existing connections.
28/05/2016 21:30:32.200 [NOTICE] Closing old Socks listener on 127.0.0.1:9150
28/05/2016 21:30:32.200 [WARN] connection_connect_sockaddr(): Bug: Tried to open a socket with DisableNetwork set. (on Tor 0.2.7.6 7a489a6389110120)
28/05/2016 21:30:32.200 [WARN] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 1; recommendation warn; host 7BE683E65D48141321C5ED92F075C55364AC7123 at 193.23.244.244:443)
28/05/2016 21:30:36.000 [NOTICE] Delaying directory fetches: DisableNetwork is set.
**Trac**:
**Username**: tazmin98https://gitlab.torproject.org/tpo/core/tor/-/issues/19196[prop250] Shared random version parsing fails on 32 bit2020-06-27T13:58:55Zteor[prop250] Shared random version parsing fails on 32 bitIn dgoulet's srv-testing-2, git 0234595:
The original patch to sr_parse_commit was:
```
- version = (uint32_t) tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
+ version = (uint32_t) tor_parse_ulong(value, 10, 1, UINT32_MAX, NULL...In dgoulet's srv-testing-2, git 0234595:
The original patch to sr_parse_commit was:
```
- version = (uint32_t) tor_parse_long(value, 10, 1, UINT32_MAX, NULL, NULL);
+ version = (uint32_t) tor_parse_ulong(value, 10, 1, UINT32_MAX, NULL, NULL);
```
Since this is a regression, it's worth noting that the unit test `shared-random/sr_commit` tests version parsing as part of commit parsing. It will fail on 32 bit platforms if we make this mistake again. (I can't see any way to make it fail on 64-bit platforms - using fixed-size integers with a function that takes platform-dependent-size integers is inherently error-prone, see legacy/trac#19063.)
Also, since this is a regression, can you please make sure that no other patches from the last few comments in legacy/trac#16943 were dropped?https://gitlab.torproject.org/tpo/core/tor/-/issues/19195[prop250] Remove unnecessary assertion in sr_compute_srv2020-06-27T13:58:56Zteor[prop250] Remove unnecessary assertion in sr_compute_srvIn dgoulet's srv-testing-2, git 0234595:
In sr_compute_srv, this doesn't make much sense:
```
uint64_t reveal_num;
...
tor_assert(reveal_num < UINT64_MAX);
```
Why stop reveal_num being equal to UINT64_MAX?
There's absolutely no harm i...In dgoulet's srv-testing-2, git 0234595:
In sr_compute_srv, this doesn't make much sense:
```
uint64_t reveal_num;
...
tor_assert(reveal_num < UINT64_MAX);
```
Why stop reveal_num being equal to UINT64_MAX?
There's absolutely no harm in it being equal.
Let's just delete the condition.
(Or provide a comment saying why we're checking.)Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19193AudioContext, HTMLMediaElement, and MediaStream provide currentTime to conten...2020-06-27T14:39:09ZArthur EdelsteinAudioContext, HTMLMediaElement, and MediaStream provide currentTime to content scriptsThe worst offender is probably AudioContext, where you can get
the current time thus:
```
var audioContext = new AudioContext();
audioContext.currentTime;
```
Similarly, HTMLVideoElement.currentTime, HTMLAudioElement.currentTime, and C...The worst offender is probably AudioContext, where you can get
the current time thus:
```
var audioContext = new AudioContext();
audioContext.currentTime;
```
Similarly, HTMLVideoElement.currentTime, HTMLAudioElement.currentTime, and CanvasCaptureMediaStream.currentTime can each be used as a time source with resolution better than 10 ms.https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19192untrust bluecoat CA2020-06-27T14:39:09ZNima Fatemiuntrust bluecoat CAApparently BlueCoat [now has a signed CA](https://crt.sh/?id=19538258). Can we please make sure it's not trusted in the Tor Browser?Apparently BlueCoat [now has a signed CA](https://crt.sh/?id=19538258). Can we please make sure it's not trusted in the Tor Browser?https://gitlab.torproject.org/tpo/core/tor/-/issues/19191{BUG} directory_send_command: Bug: Squid does not like URLs longer than 4095 ...2020-06-27T13:58:56Zfk{BUG} directory_send_command: Bug: Squid does not like URLs longer than 4095 bytes, and this one is 20515 bytes longAfter upgrading the relay 40A60D1F1E8AFBED22FCB30B3FBE2E275A14CF99 to Tor v0.2.8.3-alpha I got the following warning after starting:
```
May 27 14:02:26.111 [warn] {BUG} directory_send_command: Bug: Squid does not like URLs longer than ...After upgrading the relay 40A60D1F1E8AFBED22FCB30B3FBE2E275A14CF99 to Tor v0.2.8.3-alpha I got the following warning after starting:
```
May 27 14:02:26.111 [warn] {BUG} directory_send_command: Bug: Squid does not like URLs longer than 4095 bytes, and this one is 20515 bytes long: /tor/server/d/0E2ED00342161B68622BDF90623068BD9FF56890+0E3A7F3C5F[...]
```
It was repeated a couple of times with slightly different paths.
This relay was previously running 0.2.7.6, but I'm also using 0.2.8.2-alpha on
other systems and haven't seen the warnings there.
I'm not sure if there's a connection, but bootstrapping did not make it beyond 80%.
Enabling debug logging resulted in lots of messages like:
```
May 27 14:27:16.604 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.605 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.605 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.606 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.606 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.607 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.607 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:16.608 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:27.346 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:30.560 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:33.302 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
May 27 14:27:33.717 [info] {NET} get_interface_address6_via_udp_socket_hack: Address that we determined via UDP socket magic is unsuitable for public comms.
```
Tor is running in an ElectroBSD jail without raw socket access (which is probably required for the UDP socket magic to work).
After adding the Address directive bootstrapping worked and the relay is currently serving traffic.Tor: 0.2.8.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19190Teach scripts/maint/format_changelog.py about links to bugs2020-06-27T13:58:56ZNick MathewsonTeach scripts/maint/format_changelog.py about links to bugsRoger points out it would be cool if scripts/maint/format_changelog.py -B were to output links to trac.Roger points out it would be cool if scripts/maint/format_changelog.py -B were to output links to trac.Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19189Work around gold bug in Tor Browser2020-06-27T14:39:09ZGeorg KoppenWork around gold bug in Tor BrowserWhile bisecting on my Debian box I am always hitting https://bugzilla.mozilla.org/show_bug.cgi?id=1233963. We should backport the fix to include it at least in the alpha series. Given that https://hg.mozilla.org/mozilla-central/rev/1a4c4...While bisecting on my Debian box I am always hitting https://bugzilla.mozilla.org/show_bug.cgi?id=1233963. We should backport the fix to include it at least in the alpha series. Given that https://hg.mozilla.org/mozilla-central/rev/1a4c479ec7cd is pretty simple having this one in the stable series as well can't hurt.https://gitlab.torproject.org/tpo/tpa/team/-/issues/19188Create CNAME record for get.ooni.torproject.org2020-06-27T14:19:24ZArturo FilastòCreate CNAME record for get.ooni.torproject.orgWe need to have another subdomain to use for hosting the raspberry pi images for ooniprobe and other packages.
Can we have configured a CNAME pointer from `get.ooni.torproject.org` to `get.ooni.io`?
Thanks!We need to have another subdomain to use for hosting the raspberry pi images for ooniprobe and other packages.
Can we have configured a CNAME pointer from `get.ooni.torproject.org` to `get.ooni.io`?
Thanks!https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19187Backport popup related ASan crash fix to Tor Browser 6.x2020-06-27T14:39:09ZGeorg KoppenBackport popup related ASan crash fix to Tor Browser 6.xIt turns out that one of the crashes I found with ASan got already reported a couple of days earlier and fixed on trunk. The security rating indicates that Mozilla won't backport that patch to ESR 45. But we should do for safety's sake.It turns out that one of the crashes I found with ASan got already reported a couple of days earlier and fixed on trunk. The security rating indicates that Mozilla won't backport that patch to ESR 45. But we should do for safety's sake.Georg KoppenGeorg Koppenhttps://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19186KeyboardEvents are only rounding to 100ms2020-06-27T14:39:09ZArthur EdelsteinKeyboardEvents are only rounding to 100msIn legacy/trac#1517, the idea was to round most event time stamps to 100ms, but to round KeyboardEvent.timeStamp to 250 ms (see https://trac.torproject.org/projects/tor/ticket/1517#comment:25).
Our current patch for legacy/trac#1517 is ...In legacy/trac#1517, the idea was to round most event time stamps to 100ms, but to round KeyboardEvent.timeStamp to 250 ms (see https://trac.torproject.org/projects/tor/ticket/1517#comment:25).
Our current patch for legacy/trac#1517 is [here](https://gitweb.torproject.org/tor-browser.git/commit/?h=tor-browser-45.1.1esr-6.0-1&id=191e520147e00b1a103b9fd91ad37fa4b0cf9d28).
However, when I test KeyboardEvents in the latest Tor Browser, I only see rounding to 100 ms. With the debugger I observed that calling myKeyboardEvent.timeStamp in the browser console is calling Event::TimeStamp() instead of KeyboardEvent::TimeStamp. So we're apparently failing to properly override the Event::TimeStamp call.Arthur EdelsteinArthur Edelsteinhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19185Drop tidbit about tor-ops@ from man page2021-07-22T16:23:44ZDamian JohnsonDrop tidbit about tor-ops@ from man pageSebastian made the good point that we mention tor-ops@ in the man page. We should stop. The man page would do just as well without this sentence...
```
[[AuthoritativeDirectory]] **AuthoritativeDirectory** **0**|**1**::
When this op...Sebastian made the good point that we mention tor-ops@ in the man page. We should stop. The man page would do just as well without this sentence...
```
[[AuthoritativeDirectory]] **AuthoritativeDirectory** **0**|**1**::
When this option is set to 1, Tor operates as an authoritative directory
server. Instead of caching the directory, it generates its own list of
good servers, signs it, and sends that to the clients. Unless the clients
already have you listed as a trusted directory, you probably do not want
to set this option. Please coordinate with the other admins at
tor-ops@torproject.org if you think you should be a directory.
```Tor: 0.2.9.x-finalhttps://gitlab.torproject.org/tpo/applications/tor-browser-build/-/issues/19182Find a better place for the Mac OS X SDK we need for our Tor Browser builds2022-08-02T14:24:37ZGeorg KoppenFind a better place for the Mac OS X SDK we need for our Tor Browser buildsRight now we host the OS X SDK we use for our Tor Browser builds on our infrastructure. We might want to find a better solution for that.Right now we host the OS X SDK we use for our Tor Browser builds on our infrastructure. We might want to find a better solution for that.https://gitlab.torproject.org/tpo/core/tor/-/issues/19180Add new compiler warnings2020-06-27T13:58:56ZNick MathewsonAdd new compiler warningsWhile doing legacy/trac#19044 I tried to sort all the GCC warnings to see if we missed any that we could add. I came up with a list that we could add without triggering any new warnings (for me), and a list of ones tthat maybe looked go...While doing legacy/trac#19044 I tried to sort all the GCC warnings to see if we missed any that we could add. I came up with a list that we could add without triggering any new warnings (for me), and a list of ones tthat maybe looked good, but which do trigger today. I'm thinking that we can add these with little to no trouble:
```
-Wunused-but-set-parameter -Wunused -Wuninitialized -Wstrict-aliasing=5
-Wswitch-bool -Wtrampolines -Wunused-but-set-variable -Wvariadic-macros
-Wsync-nand -Wdate-time -Wsizeof-array-argument
-Wunused-parameter -Wunused-local-typedefs
-Wshift-count-negative -Wshift-count-overflow
-Wc99-c11-compat -Wcast-align -Wpacked
-Wmissing-format-attribute -Wsuggest-attribute=noreturn -Wsuggest-attribute=format
```
And we can add these GCC-6 only options with little to no trouble:
```
-Wshift-negative-value -Wshift-overflow=2 -Wignored-attributes
```
These warnings look useful but they trigger on our current code. Is it worth fixing these warnings?
```
-Wconversion
-Wsign-conversion
-Wunsafe-loop-optimizations
-Waggregate-return // one place only, I believe.
-Wdouble-promotion // Pretty easy to fix.
-Wunsuffixed-float-constants // We have these all over.
-Wcast-qual
-Wstrict-overflow=n
-Wstrict-overflow
-Wpadded
-Wjump-misses-init // lots of these; are any bugs?
-Wswitch-default
-Wsuggest-attribute=pure
-Wsuggest-attribute=const
-Wfloat-conversion // just a dozen or so.
-Woverlength-strings // only in tests
```
And these gcc6-only warnings trigger on our current code:
```
-Wnull-dereference
-Wunused-const-variable
-Wduplicated-cond
```Tor: 0.2.9.x-finalNick MathewsonNick Mathewsonhttps://gitlab.torproject.org/tpo/core/tor/-/issues/19179Refactor functions that handle 'packages' in consensus/votes2021-09-16T14:33:29ZGeorge KadianakisRefactor functions that handle 'packages' in consensus/votesThis is a side issue of legacy/trac#18840.
The code managing packages for consensuses and votes seems to be of particularly low quality.
See compute_consensus_package_lines() doing ad-hoc parsing. And see validate_recommended_package_l...This is a side issue of legacy/trac#18840.
The code managing packages for consensuses and votes seems to be of particularly low quality.
See compute_consensus_package_lines() doing ad-hoc parsing. And see validate_recommended_package_line() doing more ad-hoc parsing and having wrong return value patterns. Fortunately, both of them are weakly tested in the unittests.
Maybe we should refactor and add more testing for these funcs?Tor: unspecifiedhttps://gitlab.torproject.org/tpo/tpa/team/-/issues/19178Please install perl module DateTime2020-06-27T14:19:25ZLinus Nordberglinus@torproject.orgPlease install perl module DateTimeperdulce used to have the perl module DateTime installed. Can it be installed again?
It's needed for ~linus/usr/bin/prune-old-builds.perdulce used to have the perl module DateTime installed. Can it be installed again?
It's needed for ~linus/usr/bin/prune-old-builds.https://gitlab.torproject.org/tpo/core/tor/-/issues/19177another free() crash2020-06-27T13:58:57Ztoralfanother free() crashthis is still on commit 0f80dd2 - maybe just another variant of legacy/trac#19128 or legacy/trac#19175 :
```
============================================================ T= 1464221042
Tor 0.2.8.2-alpha-dev (git-684babee8491c3e9) died: Ca...this is still on commit 0f80dd2 - maybe just another variant of legacy/trac#19128 or legacy/trac#19175 :
```
============================================================ T= 1464221042
Tor 0.2.8.2-alpha-dev (git-684babee8491c3e9) died: Caught signal 11
/usr/bin/tor(+0x1435c9)[0x7a2491b5c9]
/lib64/libc.so.6(cfree+0x14)[0x3aaf152f244]
/lib64/libc.so.6(cfree+0x14)[0x3aaf152f244]
/usr/bin/tor(tor_cert_free+0x51)[0x7a2487bca1]
/usr/bin/tor(+0x86cef)[0x7a2485ecef]
/usr/bin/tor(+0x8c4c0)[0x7a248644c0]
/usr/bin/tor(routerlist_remove_old_routers+0x665)[0x7a24866bb5]
/usr/bin/tor(+0x3d615)[0x7a24815615]
/usr/bin/tor(+0x57ac3)[0x7a2482fac3]
/usr/lib64/libevent-2.0.so.5(event_base_loop+0xcc0)[0x3aaf27d3840]
/usr/bin/tor(do_main_loop+0x235)[0x7a248190c5]
/usr/bin/tor(tor_main+0x1b35)[0x7a2481c745]
/usr/bin/tor(main+0x2b)[0x7a248146ab]
/lib64/libc.so.6(__libc_start_main+0x114)[0x3aaf14cd734]
/usr/bin/tor(_start+0x29)[0x7a248146f9]
```
and gdb out is
```
Program received signal SIGSEGV, Segmentation fault.
__GI___libc_free (mem=0x64656d616e6e55) at malloc.c:2945
2945 malloc.c: No such file or directory.
#0 __GI___libc_free (mem=0x64656d616e6e55) at malloc.c:2945
#1 0x0000007a2487bca1 in tor_cert_free (cert=0x7a2bfb3830)
at src/or/torcert.c:119
#2 0x0000007a2485ecef in signed_descriptor_free (sd=0x7a2d0410e0)
at src/or/routerlist.c:2935
#3 0x0000007a24863fd6 in routerlist_remove_old (rl=<optimized out>,
sd=<optimized out>, idx=<optimized out>, idx@entry=1242)
at src/or/routerlist.c:3309
#4 0x0000007a248644c0 in routerlist_remove_old_cached_routers_with_id (
now=now@entry=1464221041, cutoff=cutoff@entry=1463789041,
lo=lo@entry=1241, hi=hi@entry=1243, retain=retain@entry=0x7a2cd11040)
at src/or/routerlist.c:3821
#5 0x0000007a24866bb5 in routerlist_remove_old_routers ()
at src/or/routerlist.c:3940
#6 0x0000007a24815615 in check_descriptor_callback (now=1464221041,
options=<optimized out>) at src/or/main.c:1858
#7 0x0000007a2482fac3 in periodic_event_dispatch (fd=<optimized out>,
what=<optimized out>, data=0x7a24c20340 <periodic_events+512>)
at src/or/periodic.c:52
#8 0x000003aaf27d3840 in event_process_active_single_queue (
activeq=0x7a282e6cd0, base=0x7a282e7ab0)
at /var/tmp/portage/dev-libs/libevent-2.0.22/work/libevent-2.0.22-stable/event.c:1368
#9 event_process_active (base=<optimized out>)
at /var/tmp/portage/dev-libs/libevent-2.0.22/work/libevent-2.0.22-stable/event.c:1438
#10 event_base_loop (base=0x7a282e7ab0, flags=flags@entry=0)
at /var/tmp/portage/dev-libs/libevent-2.0.22/work/libevent-2.0.22-stable/event.c:1639
#11 0x0000007a248190c5 in run_main_loop_once () at src/or/main.c:2537
#12 run_main_loop_until_done () at src/or/main.c:2583
#13 do_main_loop () at src/or/main.c:2509
#14 0x0000007a2481c745 in tor_main (argc=<optimized out>, argv=<optimized out>)
at src/or/main.c:3638
#15 0x0000007a248146ab in main (argc=<optimized out>, argv=<optimized out>)
at src/or/tor_main.c:30
warning: target file /proc/1917/cmdline contained unexpected null characters
Saved corefile /root/core
(gdb) quit
A debugging session is active.
Inferior 1 [process 1917] will be detached.
Quit anyway? (y or n) [answered Y; input not from terminal]
Detaching from program: /usr/bin/tor, process 1917
```
Neither gdb nor tor are running but I do have a core file (and the logs)https://gitlab.torproject.org/tpo/applications/tor-browser/-/issues/19176Language packs are not rezipped deterministically2020-06-27T14:39:10ZGeorg KoppenLanguage packs are not rezipped deterministicallyMy patch for legacy/trac#18915 forgot to use our deterministic zip wrapper and used `zip` directly with foreseeable results.My patch for legacy/trac#18915 forgot to use our deterministic zip wrapper and used `zip` directly with foreseeable results.https://gitlab.torproject.org/tpo/core/tor/-/issues/19175free(): invalid next size (fast)2020-06-27T13:58:57Ztoralffree(): invalid next size (fast)stumpled over the following cor git commit 0f80dd2
```
Program received signal SIGABRT, Aborted.
0x000003d47f7ff37b in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
55 ../sysdeps/unix/sysv/linux/raise.c: ...stumpled over the following cor git commit 0f80dd2
```
Program received signal SIGABRT, Aborted.
0x000003d47f7ff37b in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
55 ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
#0 0x000003d47f7ff37b in __GI_raise (sig=sig@entry=6)
at ../sysdeps/unix/sysv/linux/raise.c:55
#1 0x000003d47f8009e1 in __GI_abort () at abort.c:89
#2 0x000003d47f842b4d in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x3d47f942988 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/posix/libc_fatal.c:175
#3 0x000003d47f848e2f in malloc_printerr (action=3,
str=0x3d47f942a98 "free(): invalid next size (fast)", ptr=<optimized out>,
```
full gdb output will be attached b/c this stupid trac doesn't allow me to file it here.Tor: 0.2.8.x-finalNick MathewsonNick Mathewson