Tor Launcher extension hangs periodically when Tor Browser is started
Sometimes i observe that Tor Browser firefox browser window is not coming up after progress dialog completed. The process "firefox.exe" can be found within process list, but it never become visible or exit. Each further launch of Tor Browser creates another firefox.exe, which will never open it's window. If i terminate the hanged firefox processes manually, then next launch of Tor Browser completes successfully. I have did a research and found that the hang happen in Tor Launcher extension in file tl-protocol.js in the call of "readBytes" method. There is also a related comment in source code:
// TODO: readBytes() will sometimes hang if the control connection is opened // immediately after tor opens its listener socket. Why?
So, i assume, the problem is known to you, but is still not fixed.
Tested OS: WinXP Tor Browser Bundle version: 3.5.1
Trac:
Username: trlaunch01
Activity
We placed the TODO comment in the code because we encountered some hangs during development of Tor Launcher (if I remember correctly, the hang occurred the first time Tor Launcher issued a control port command which is long before the progress dialog finishes). We do not know the root cause and we do not know how to reproduce the problem.
If you make sure that no tor.exe of firefox.exe processes are running before you open "Start Tor Browser.exe", how often does this hang occur?
To help us debug the problem, please do the following:
- Start TBB (you'll have to get past the hang)
- Open about:config
- Change extensions.torlauncher.loglevel to 0
- Change extensions.torlauncher.logmethod to 0
- Exit the Tor Browser
- From a cmd prompt, cd to the Browser subdirectory within TBB and start the browser by using the command: firefox -console
If you can reproduce the hang with the above debugging enabled, please send us the log output from the Console window.
it's related to #9531 (moved) Reason is https://bugzilla.mozilla.org/show_bug.cgi?id=698882
Trac:
Username: trlaunch01-
I was able to reproduce hang when launched firefox -console with tuned log level. Please see all console output in attached file tor_log.txt
General remark: bug reproduces oftenly(each 3d time) when system is under load(for example intensive disk writes), or rarely otherwise
Trac:
Username: trlaunch01 
Closed #12983 (moved) as duplicate of this.
Trac:
Cc: gk, mcs to gk, mcs, Emory, Hubbard-
Closed #13058 (moved) as duplicate.
Trac:
Cc: gk, mcs, Emory+Hubbard to gk, mcs, Emory+Hubbard, Manstein -
Closed #12887 (moved) as duplicate.
Trac:
Cc: gk, mcs, Emory+Hubbard, Manstein to gk, mcs, Emory+Hubbard, Manstein, mjdbb1 -
It seems that if I disable the addon "HTTPS-Everywhere 4.0.0" I can no longer replicate this issue on any machine I've tried.
Edit: As soon as I wrote that I discovered #13072 (moved): https://trac.torproject.org/projects/tor/ticket/13072
Same issue?
Trac:
Username: mjdbb1 -
Marked #13072 (moved) as duplicate of this.
Trac:
Cc: gk, mcs, Emory+Hubbard, Manstein, mjdbb1 to gk, mcs, Emory+Hubbard, Manstein, mjdbb1, Gravitas Hang that coming up after progress dialog completed is not about Tor Launcher.
Hang happens only with blocking socket, so it could to happen on
TorSendCommandorTorRetrieveBootstrapStatusand friends, which unlikely could to bypass hang onwriteBytesand to hang onreadBytes()latter. And if thread hangs then why progress window vanishes?More likely two different bugs in here, hang in
readBytes()of Tor Launcher long before progress completes, and hang triggered bytorbutton_local_tor_checkof Torbutton just after progress completes and before browser window should to appear. You can to reproduce it, placewhile(true){}loop to begin oftorbutton_send_ctrl_cmdand observe the same as described behavior.-
Replying to cypherpunks:
More likely two different bugs in here, hang in
readBytes()of Tor Launcher long before progress completes, and hang triggered bytorbutton_local_tor_checkof Torbutton just after progress completes and before browser window should to appear. You can to reproduce it, placewhile(true){}loop to begin oftorbutton_send_ctrl_cmdand observe the same as described behavior.Thanks cypherpunks. You may be correct about there being two different hangs, but I am most suspicious of the interaction between HTTPS Everywhere's check.t.o connection (see ticket:9693#comment:5) and the torbutton_local_tor_check().
Unfortunately, I have only been able to very very very rarely reproduce a hang (and only when I have been unprepared to debug it). Adding a while(true) loop inside torbutton_send_ctrl_cmd() causes what appears to be a hang, but if I change it to a "for (var i = 0; i < 1000; ++i)" loop, then normal startup finishes after the for loop is done. So that is not a true deadlock situation.
Gravitas -- thank you for all of your debugging in #13072 (moved). Can you try an experiment? Use about:config to toggle extensions.torbutton.local_tor_check to false and also set extensions.torbutton.test_url to an empty string. Modifying those two prefs will effectively disable all checks done by Torbutton. I'd like to know if doing this eliminates the hang.
Separately, you could also experiment by commenting out this line in HTTPS Everywhere: this.testProxySettings(); (inside ssl-observatory.js).
-
Sure, will try the experiments you recommended and get back to you in a day, max two. It hangs about 1 in 4 times on startup on my machine, so reproducing it is no problem. As I mentioned in the previous post, its probably because my machine is quite speedy (its a 12 core Xeon).
Trac:
Username: Gravitas -
Your intuition seems to be correct. I used about:config to toggle extensions.torbutton.local_tor_check to false, and also set extensions.torbutton.test_url to an empty string. I restarted 25 times, and it worked flawlessly. I then reset said settings back their defaults, and got a hang on try number 2.
I then commented out "this.testProxySettings();" inside ssl-observatory.js. I restarted 25 times, and it worked flawlessly. I then commented the line in again, and got a hang on tries number 6, 7 and 8.
I am happy to run any more tests that you would like.
Version: I was using HTTPS-Everywhere v4.0.1 (which may be slightly different to the default one supplied with Tor Browser). In any case, this particular bug exhibits itself with all versions of HTTPS-Everywhere.
Trac:
Username: Gravitas but I am most suspicious of the interaction between HTTPS Everywhere's check.t.o connection (see ticket:9693#comment:5) and the torbutton_local_tor_check().
It's the same problem as diagnosed and fixed for hang on New Identity control port access by #9531 (moved), torbutton_local_tor_check() using control port on browser start-up.
So that is not a true deadlock situation.
Yes, it was imitation of deadlock which triggered on start-up while accessing control port soon after TLS connection somewhere in browser launched.
-
Trac:
Username: asmith Trac:
nonblocking.patch-
Gravitas, can you try to test with attached patch?
Although I'm familiar with C/C++/C#, I've never used JavaScript.
I tried downloading both versions of TorBrowser for Windows (3.6.6 and 4.0-alpha-3) and searching all *.js files for the text inside the patch, with no luck.
Could you point me in the right direction for some instructions on how to test the patch "0001-Fix.patch"? The easiest way would be if you attached a .zip file that contained a modified version of Tor Browser, so I could download and test it out. I can also provide links to an anonymous FTP server if this would be easier.
Trac:
Username: Gravitas Replying to Gravitas:
Could you point me in the right direction for some instructions on how to test the patch "0001-Fix.patch"?
Patch was shipped with new Torbutton version for Tor Browser 3.6.6. It should to fix hang. Can you confirm?
Replying to muckybucket:
I am still having this issue with Tor Browser 3.6.6
Replying to mjdbb1:
I too am still experiencing the issue on 3.6.6 (although I will say it doesn't seem to be as frequent). Again, if I disable HTTPS-Anywhere, it seems to be completely gone.
Replying to trlaunch01:
On my side the issue also became a bit more rare with 3.6.6. But it is still in. I would be glad to check if the problem reproduces without HTTPS-Anywhere, but cannot do this because HTTPS-Anywhere is a required option for me
What number of cores reported for your hosts, folks? (what CPU installed?)
-
Dell T7500, dual Xeon CPU, each CPU has 6 cores running @ 2.66Ghz, Hyperthreading turned on, for a total of 24 hyperthreaded cores. SSD has read/write speeds of 200MByte/sec.
On my machine, it used to hang consistently around 25% of the time on startup, with the latest version 3.66, it is rock solid (see my post above).
Trac:
Username: Gravitas -
What number of cores reported for your hosts, folks? (what CPU installed?) The issue does not depend directly on number of cores. It produces on processors with single, dual and quad cores. Approximately 1 of 30 launches of Tor Browser leads to hung. The problem can be reproduced very oftenly if hard disk is under load by some other app. When i modified the code of Tor Launcher extension and inserted "Sleep(5seconds)" right after creation of connection to tor process and before sending any commands, the problem stopped reproducing on my side - just for you information
Trac:
Username: trlaunch01 When i modified the code of Tor Launcher extension and inserted "Sleep(5seconds)" right after creation of connection to tor process and before sending any commands, the problem stopped reproducing on my side - just for you information
Could you to post all code you inserted? (As I know, JS have no support for Sleep() command).
Replying to testhang:
Anybody with:
- some free time
- bug reproducibility (easy to do if 0001-Fix.patch reverted for torbutton)
- resources to build browser (64bit platform and 4G+ virt mem minimum) Could you to contact me (email: testhang (at) sigaint.org) to test c++ (two-line) patch?
Can you post the patch here?
Possibly someone could create a build with your patch and someone else could test.
I haven't been able to reproduce the bug within Tor Launcher (even before Torbutton was patched) so I am not a candidate to confirm that the bug is fixed.
-
-
Trac:
Username: testhang -
-
Possible duplicates: #15182 (moved) and #15669 (moved).
Replying to cypherpunks:
it's related to #9531 (moved) Reason is https://bugzilla.mozilla.org/show_bug.cgi?id=698882 Mozilla's adventures continue in https://bugzilla.mozilla.org/show_bug.cgi?id=1279163, and the bug is marked fixed for FF48, but it was backed out, because it worked only with the new shiny MustDie compiler! (so Mozilla promises it for FF49.) TBB doesn't have such awful dependencies, so does anybody want to backport the fix?
Trac:
Reviewer: N/A to N/A
Sponsor: N/A to N/A
Severity: N/A to Normalmentioned in issue #10827 (closed)
mentioned in issue #12746 (moved)
mentioned in issue #12887 (moved)
mentioned in issue #12983 (moved)
mentioned in issue #13058 (moved)
mentioned in issue #13072 (moved)
mentioned in issue #13235 (moved)
mentioned in issue #13651 (moved)
mentioned in issue #15182 (moved)
mentioned in issue #15669 (moved)
