[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #24826 [Core Tor/Tor]: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely (was: LZMA-compressed consensus diffs stall Tor Browser launch for at least 20s or break it entirely)

#24826: LZMA- and Zstandard compressed consensus diffs stall Tor Browser launch for
at least 20s or break it entirely
--------------------------+------------------------------------
 Reporter:  gk            |          Owner:  (none)
     Type:  defect        |         Status:  new
 Priority:  Medium        |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor  |        Version:
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Old description:

> In #22341 we are thinking about picking up LZMA- and zstd-support for
> consensus diffs.
>
> For LZMA-compressed diffs I often encounter boostrap delays of at least
> 20s like this:
> {{{
> Dec 26 21:01:18.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was
> labeled as LZMA compressed, and it seems to be LZMA compressed.
> Dec 26 21:01:38.000 [info] handle_response_fetch_consensus(): Applied
> consensus diff (size 482897) from server 'XX.XX.XX.XX:9001', resulting in
> a new consensus document (size 1903167).
> }}}
>
> But, worse, it might even break Tor Browser bootstrap entirely when
> blocking a Tor Launcher `GETCONF` call (throwing an exception as Tor
> Launcher thinks tor is not working) like so:
> {{{
> Dec 30 23:54:54.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was
> labeled as LZMA compressed, and it seems to be LZMA compressed.
> Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError:
> s.split is not a function
> Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError:
> s.split is not a function
> [12-30 22:54:55] TorLauncher DBUG: readTorSettings
> ----------------------------------------------
> [12-30 22:54:55] TorLauncher DBUG: Sending Tor command: GETCONF
> UseBridges
> [12-30 22:55:10] TorLauncher NOTE: Exception on control port
> [Exception... "Component returned failure code: 0x804b000e
> (NS_ERROR_NET_TIMEOUT) [nsIBinaryInputStream.readBytes]"  nsresult:
> "0x804b000e (NS_ERROR_NET_TIMEOUT)"  location: "JS frame ::
> jar:file:///home/thomas/Arbeit/TBB/tor-browser_en-
> US/Browser/TorBrowser/Data/Browser/profile.default/extensions/tor-
> launcher@xxxxxxxxxxxxxxxxxx!/components/tl-protocol.js ::
> TorProtocolService.prototype._torReadLine :: line 920"  data: no]
> }}}

New description:

 In #22341 we are thinking about picking up LZMA- and Zstandard-support for
 consensus diffs.

 For LZMA-compressed diffs I often encounter boostrap delays of at least
 20s like this:
 {{{
 Dec 26 21:01:18.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was
 labeled as LZMA compressed, and it seems to be LZMA compressed.
 Dec 26 21:01:38.000 [info] handle_response_fetch_consensus(): Applied
 consensus diff (size 482897) from server 'XX.XX.XX.XX:9001', resulting in
 a new consensus document (size 1903167).
 }}}

 But, worse, it might even break Tor Browser bootstrap entirely when
 blocking a Tor Launcher `GETCONF` call (throwing an exception as Tor
 Launcher thinks tor is not working) like so:
 {{{
 Dec 30 23:54:54.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was
 labeled as LZMA compressed, and it seems to be LZMA compressed.
 Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError:
 s.split is not a function
 Illegal AddressMatcher: [xpconnect wrapped nsIPrefBranch] -- TypeError:
 s.split is not a function
 [12-30 22:54:55] TorLauncher DBUG: readTorSettings
 ----------------------------------------------
 [12-30 22:54:55] TorLauncher DBUG: Sending Tor command: GETCONF UseBridges
 [12-30 22:55:10] TorLauncher NOTE: Exception on control port [Exception...
 "Component returned failure code: 0x804b000e (NS_ERROR_NET_TIMEOUT)
 [nsIBinaryInputStream.readBytes]"  nsresult: "0x804b000e
 (NS_ERROR_NET_TIMEOUT)"  location: "JS frame ::
 jar:file:///home/thomas/Arbeit/TBB/tor-browser_en-
 US/Browser/TorBrowser/Data/Browser/profile.default/extensions/tor-
 launcher@xxxxxxxxxxxxxxxxxx!/components/tl-protocol.js ::
 TorProtocolService.prototype._torReadLine :: line 920"  data: no]
 }}}

--

Comment (by gk):

 Turns out this is affecting Zstandard-compressed diffs as well:
 {{{
 Jan 10 07:55:33.000 [debug] HTTP body from server 'XX.XX.XX.XX:9001' was
 labeled as Zstandard compressed, and it seems to be Zstandard compressed.
 Jan 10 07:55:53.000 [info] handle_response_fetch_consensus(): Applied
 consensus diff (size 522839) from server 'XX.XX.XX.XX:9001', resulting in
 a new consensus document (size 1866898).
 }}}
 This time it hit the 2 second Torbutton timeout breaking the local SOCKS
 port check.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24826#comment:8>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs