Opened 10 months ago

Last modified 10 months ago

#29497 needs_information defect

After tor crash, firefox.exe (tor browser) shoots up to 50+% cpu usage and stays there til killed in task list

Reported by: cypherpunks Owned by: tbb-team
Priority: High Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-circuit-display, tbb-8.0-issues, tbb-regression
Cc: igt0, arthuredelstein Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

re: Tor Browser 8.0.6 (and also 8.0.3)

Have noticed since 8.0.3 to 8.0.6 that, every time tor crashes, firefox.exe (tor browser) shoots up to 50-60% cpu usage and stays there until i restart the whole browser or kill the process in the task list, thus losing all tabs.

Can we get a fix for this? It's annoying to have to save all tabs, restart, and then reload them again.

Child Tickets

Change History (8)

comment:1 Changed 10 months ago by cypherpunks

The same for non-exe platform.

comment:2 Changed 10 months ago by mcs

Kathy and I spent a little time on this ticket to try to narrow down when this problem was introduced. We were able to reproduce the problem on macOS with Tor Browser 8.0 or newer (and it is probably reproducible using any esr60-based Tor Browser).

Here are the steps we followed:

  1. Open a clean Tor Browser.
  2. Click Connect to connect directly to the Tor network.
  3. Send a TERM signal to the tor.real process (e.g., killall tor.real)
  4. Dismiss the "Tor unexpectedly exited" prompt.

At that point, the main Firefox process will be in a busy loop (consuming approximately 100% CPU). We could not reproduce the problem with Tor Browser 7.5.6 (the last esr52-based release).

As other people have pointed out, the only way to recover from this condition seems to be to restart the browser. We have not tracked down the exact cause, but when it is in this state the firefox process seems to be making a lot of select() system calls.

We also did an experiment where we disabled Tor Launcher, started a standalone copy of tor.real in TCP port 9150, and then started Tor Browser (we wanted to make sure the code in Tor Launcher that monitors the control port was not at fault). The 100% CPU issue also occurred after we killed that copy of tor.real. This combined with the high frequency of select() calls suggests that there may be a bug in Tor Browser's SOCKS code. A good next step would be to try to reproduce this issue with Firefox.

comment:3 Changed 10 months ago by cypherpunks

extensions.torbutton.display_circuit
Bug stopped when it is set to false.

comment:4 in reply to:  3 Changed 10 months ago by mcs

Cc: igt0 arthuredelstein added
Status: newneeds_information

Replying to cypherpunks:

extensions.torbutton.display_circuit
Bug stopped when it is set to false.

Ah ha! Thanks for tracking that down.

What happens when tor exits is that the code inside src/modules/tor-control-port.js enters a tight loop in which the awaitNextChunk() function within io.pumpInputStream() is called repeatedly. One possible fix would be to check for a zero return from scriptableInputStream.available() and shut down the circuit display monitor when that occurs (but I am not 100% sure that is a safe fix). Comments in Mozilla's code imply that the available() call should throw after the stream has closed, but apparently that is not true in all situations.

Igor and/or Arthur, do you remember why the following change was made?

Bug 26100: Use inputStream.asyncWait instead of nsIInputStreamPump
https://gitweb.torproject.org/torbutton.git/commit/?id=2764f9a0019b1eb8704e6748bfa46b9f58aaf74a

Kathy and I were unable to get circuit display working after we switched back to nsIInputStreamPump, and we are wondering if we should try harder. We also are hoping that the reason for the above change may shed some light on this bug.

comment:5 Changed 10 months ago by cypherpunks

comment:6 in reply to:  5 Changed 10 months ago by mcs

Replying to cypherpunks:

we are wondering if we should try harder

https://github.com/lieser/dkim_verifier/commit/03a089621002e79eb54231a91f449ba61f69f642

Thanks. We did try fixing the args earlier but it seems that is not enough: no messages were received by the circuit display code. We ran out of time for debugging so I thought it might be more productive to ping Igor and Arthur in case they have already been down this path.

comment:7 Changed 10 months ago by gk

Keywords: tbb-circuit-display added
Version: Tor: unspecified

Nice bug!

comment:8 Changed 10 months ago by gk

Keywords: tbb-8.0-issues tbb-regression added
Note: See TracTickets for help on using tickets.