[tor-bugs] #8642 [TorBrowserButton]: New Identity hangs on control port activity

[Tor Bug Tracker & Wiki]

#8642: New Identity hangs on control port activity
----------------------------------------+-----------------------------------
 Reporter:  mikeperry                   |          Owner:  mikeperry
     Type:  defect                      |         Status:  new      
 Priority:  major                       |      Milestone:           
Component:  TorBrowserButton            |        Version:           
 Keywords:  tbb-crash, MikePerry201304  |         Parent:           
   Points:                              |   Actualpoints:           
----------------------------------------+-----------------------------------
 I just caught a New Identity hang in the debugger. It is hanging in one of
 the calls to torbutton_socket_readline() when sending SIGNAL NEWNYM.

 I am not sure exactly why this is happening yet.. We're using unbuffered,
 blocking sockets.. We shouldn't hang unless tor fails to ack our command,
 or Firefox is silently ignoring our unbuffered flag.

 Here's the relevant piece of the stacktrace:

 {{{
 #4  0x00007f7fb8f8ba5f in mozilla::ReentrantMonitorAutoEnter::Wait
 (this=0x7fffd9299d90,
     interval=4294967295) at
 ../../dist/include/mozilla/ReentrantMonitor.h:192
 #5  0x00007f7fba84cc6e in nsPipeInputStream::Wait (this=0x7f7f65bf3f38)
     at /srv/build-trees/build-
 alpha/x86_64/firefox-17.0.5esr/xpcom/io/nsPipe3.cpp:621
 #6  0x00007f7fba84d1bc in nsPipeInputStream::ReadSegments
 (this=0x7f7f65bf3f38,
     writer=0x7f7fba850d8a <NS_CopySegmentToBuffer(nsIInputStream*, void*,
 char const*, unsigned int, unsigned int, unsigned int*)>,
 closure=0x7f7f6a8cee70, count=1, readCount=0x7fffd9299e74)
     at /srv/build-trees/build-
 alpha/x86_64/firefox-17.0.5esr/xpcom/io/nsPipe3.cpp:747
 #7  0x00007f7fba84d39c in nsPipeInputStream::Read (this=0x7f7f65bf3f38,
     toBuf=0x7f7f6a8cee70
 "\245\245\245\245\245\245\245\245\200ofj\177\177", bufLen=1,
     readCount=0x7fffd9299e74)
     at /srv/build-trees/build-
 alpha/x86_64/firefox-17.0.5esr/xpcom/io/nsPipe3.cpp:796
 #8  0x00007f7fba8407e5 in nsBinaryInputStream::Read (this=0x7f7f6ac445e0,
     aBuffer=0x7f7f6a8cee70
 "\245\245\245\245\245\245\245\245\200ofj\177\177", aCount=1,
     aNumRead=0x7fffd9299eb8)
     at /srv/build-trees/build-
 alpha/x86_64/firefox-17.0.5esr/xpcom/io/nsBinaryStream.cpp:323
 #9  0x00007f7fba841399 in nsBinaryInputStream::ReadBytes
 (this=0x7f7f6ac445e0, aLength=1,
     _rval=0x7fffd929a128)
     at /srv/build-trees/build-
 alpha/x86_64/firefox-17.0.5esr/xpcom/io/nsBinaryStream.cpp:698
 #10 0x00007f7fba898de5 in NS_InvokeByIndex_P (that=0x7f7f6ac445e0,
 methodIndex=18, paramCount=2,
     params=0x7fffd929a110)
 }}}

 It's odd that it's using ReadSegments in there. The docs say it shouldn't
 use them if we requested unbuffered transport...

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/8642>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online