Opened 7 years ago

Closed 7 years ago

Last modified 7 years ago

#8642 closed defect (fixed)

New Identity hangs on control port activity

Reported by: mikeperry Owned by: mikeperry
Priority: High Milestone:
Component: TorBrowserButton Version:
Severity: Keywords: tbb-crash, MikePerry201304
Cc: mcs, brade Actual Points: 1
Parent ID: Points:
Reviewer: Sponsor:

Description

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...

Child Tickets

Change History (3)

comment:1 Changed 7 years ago by mikeperry

Cc: mcs brade added

Heh. Found this in nsSocketTransport::OpenOutputStream():

        // XXX if the caller wants blocking, then the caller also gets buffered!

mcs/brade: This might cause issues with your controller too, if you're still using blocking sockets. The only fix I can see is to set the segmentCount and segmentSize buffer size arguments of nsISocketTransport.openOutputStream to 1..

I'm also going to add a setTimeout call for good measure, but it doesn't look like that will actually do anything (since we timeout on the pipe, not the socket)...

comment:2 Changed 7 years ago by mikeperry

Actual Points: 1
Resolution: fixed
Status: newclosed

I haven't had a hang in my debug builds since I did this hack. I think this means it's fixed. The fix is in Torbutton 1.5.2.

comment:3 Changed 7 years ago by mcs

Thanks for the "heads up." We added a similar fix inside Tor Launcher.

Note: See TracTickets for help on using tickets.