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

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.

added component::applications/tor browser in Legacy / Trac owner::tbb-team in Legacy / Trac priority::high in Legacy / Trac severity::normal in Legacy / Trac status::needs-information in Legacy / Trac tbb-8.0-issues in Legacy / Trac tbb-circuit-display in Legacy / Trac tbb-regression in Legacy / Trac type::defect in Legacy / Trac labels

The same for non-exe platform.

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.

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

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.

Trac:
Cc: N/A to igt0, arthuredelstein
Status: new to needs_information

we are wondering if we should try harder

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

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.

Nice bug!

Trac:
Version: Tor: unspecified to N/A
Keywords: N/A deleted, tbb-circuit-display added

Trac:
Keywords: N/A deleted, tbb-regression, tbb-8.0-issues added

moved from legacy/trac#29497 (moved)

added Bug Needs Information labels and removed 1 deleted label

removed 1 deleted label

closed