Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#10382 closed defect (fixed)

Tor Launcher (TBB 3.5 build 5) hang on quit

Reported by: Sherief Owned by:
Priority: Medium Milestone:
Component: Applications/Tor Launcher Version:
Severity: Keywords:
Cc: mcs, brade Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

I experienced a Tor Launcher crash while testing TBB 3.5 build 5 Linux 64-bit [0] by trying to add a bridge then quitting out of everything. I made a video on how to reproduce the crash [1]

Also, Roger froze Tor Launcher differently but I couldn't reproduce what he did because I lack a fast internet connection.

IRC back log:
<armadev> i managed to freeze tor launcher. huh.
<Sherief> armadev: I am about to test the 64 bit of linux right now, what can I do to reproduce?
<armadev> try adding a bridge and connecting. have a very fast internet connection.
<armadev> your tor will do the first part of its bootstrap faster than tor launcher expects,
<armadev> and then tor launcher will be confused and never recover
<armadev> also it pops up windows saying "tor failed to bootstrap! your error message was: DONE"
<armadev> "Connecting to the Tor network: Done. "Open Settings" or "Quit" are my options.

[0] https://people.torproject.org/~linus/builds/3.5-rc-1-build5/TorBrowserBundle-3.5-rc-1-osx32_en-US.zip
[1] https://www.dropbox.com/s/wrtlm4elzxqdug9/torLauncherCrash.mp4

Child Tickets

Change History (7)

comment:1 Changed 6 years ago by Sherief

Summary: Tor Launcher (TBB 3.5 build 5) quit crashTor Launcher (TBB 3.5 build 5) hang on quit

comment:2 Changed 6 years ago by phoul

I am able to reproduce this issue.

Once you hit cancel, the launcher will hang, but Tor's bootstrapping process will continue to occur in the background.

comment:3 Changed 6 years ago by mcs

After some debugging, Kathy Brade and I have figured out that the "hang during quit" problems are caused by Tor Launcher's attempt to send a "SIGNAL HALT" control port command during shutdown. Apparently, Firefox ESR24 does not like to do socket I/O while shutting down when the browser never fully started up. We can fix this by just relying on the TAKEOWNERSHIP feature of tor to ensure that the tor process exits. Expect a fix soon.

I have not been able to reproduce the other problem ("tor will do the first part of its bootstrap faster than tor launcher expects, and then tor launcher will be confused and never recover" but it is possible that the change we made for #10147 fixed it... but that fix should be included in the recent 3.5rc1 builds.

comment:4 Changed 6 years ago by mcs

Resolution: fixed
Status: newclosed

Fix committed:

https://gitweb.torproject.org/tor-launcher.git/commit/130d036a14855dfd8946bfb3e689f7543306b533

If the other part of this is still a problem, let's spin off a new bug.

comment:5 in reply to:  4 ; Changed 6 years ago by Sherief

Replying to mcs:

Fix committed:

https://gitweb.torproject.org/tor-launcher.git/commit/130d036a14855dfd8946bfb3e689f7543306b533

If the other part of this is still a problem, let's spin off a new bug.

Great, does this also apply to Windows? because 3.5-rc-1 doesn't hang but leaves firefox.exe and tor.exe running in the background and TorLauncher exists smoothly. If you kill both firefox.exe and tor.exe and try to run "start tor browser.exe" it won't and will give the following log every single time you open "start tor browser":

[NOTICE] Bootstrapped 5%: Connecting to directory server. 
[WARN] connection_connect(): Bug: Tried to open a socket with DisableNetwork set.
[WARN] Problem bootstrapping. Stuck at 5%: Connecting to directory server. (Network is unreachable [WSAENETUNREACH ]; NOROUTE; count 1; recommendation warn)

The solution is to extract a new bundle.

Here's a video to see it happen:
https://www.dropbox.com/s/4yyxwp5fhn7bay9/3.5-rc1-ff-tor-running%20in%20the%20background.mp4

Last edited 6 years ago by Sherief (previous) (diff)

comment:6 in reply to:  5 ; Changed 6 years ago by mcs

Replying to Sherief:

Great, does this also apply to Windows? because 3.5-rc-1 doesn't hang but leaves firefox.exe and tor.exe running in the background and TorLauncher exists smoothly.

Since we never figured out exactly what is going wrong inside Firefox, I am not sure if the fix will help the problem you saw on Windows or not. But since most of the Firefox code is shared across platforms, I would expect the fix to affect all platforms.

Is the problem you saw where firefox.exe and tor.exe did not exit still happening?

comment:7 in reply to:  6 Changed 6 years ago by Sherief

Replying to mcs:

Replying to Sherief:

Great, does this also apply to Windows? because 3.5-rc-1 doesn't hang but leaves firefox.exe and tor.exe running in the background and TorLauncher exists smoothly.

Since we never figured out exactly what is going wrong inside Firefox, I am not sure if the fix will help the problem you saw on Windows or not. But since most of the Firefox code is shared across platforms, I would expect the fix to affect all platforms.

Is the problem you saw where firefox.exe and tor.exe did not exit still happening?

No, I wasn't to do that using TBB 3.5 or 3.5.1.

Great job.

Note: See TracTickets for help on using tickets.