[tor-bugs] #33211 [Circumvention/Snowflake]: proxy-go sometimes gets into a 100+% CPU state
Tor Bug Tracker & Wiki
blackhole at torproject.org
Wed Feb 19 23:37:49 UTC 2020
#33211: proxy-go sometimes gets into a 100+% CPU state
-------------------------------------+-----------------------------------
Reporter: dcf | Owner: (none)
Type: defect | Status: needs_information
Priority: Medium | Milestone:
Component: Circumvention/Snowflake | Version:
Severity: Normal | Resolution:
Keywords: | Actual Points:
Parent ID: | Points:
Reviewer: | Sponsor:
-------------------------------------+-----------------------------------
Comment (by dcf):
Replying to [comment:7 dcf]:
> I also had it happen again today, with the quic snowflake client from
#33336. I left the browser idle for about a half an hour, and when I came
back the fans were spinning and it was using 160–180% CPU. But just as I
started to investigate, it resolved itself spontaneously and returned to
normal levels.
I got this again just now, and this time I happened to be watching the
log. It happened right after my wifi dropped out, which caused the broker
HTTP request to stall for 5 minutes before timing out. (Side note, we
should probably reduce that timeout.) The high CPU happened immediately
after the "connection" timed out" log message. It lasted for less than a
minute, then went back to normal.
{{{
2020/02/19 23:25:49 WebRTC: Set local description
2020/02/19 23:25:49 WebRTC: Got ICE candidate: host [scrubbed]
2020/02/19 23:25:50 WebRTC: Got ICE candidate: srflx [scrubbed] related
[scrubbed]
2020/02/19 23:25:50 WebRTC: Done gathering candidates
2020/02/19 23:25:50 WebRTC: Got ICE candidate: srflx [scrubbed] related
[scrubbed]7
2020/02/19 23:25:50 WebRTC: ICEGatheringStateComplete
2020/02/19 23:25:50 Negotiating via BrokerChannel...
Target URL: snowflake-broker.azureedge.net
Front URL: ajax.aspnetcdn.com
2020/02/19 23:30:57 BrokerChannel Error: read tcp [scrubbed]->[scrubbed]:
read: connection timed out
2020/02/19 23:30:57 Failed to retrieve answer. Retrying in 10s
}}}
Possibly there is a pent-up timer or other recurrent event that creates a
lot of work while the client is blocking in the HTTP request.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33211#comment:9>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list