Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #8642

Closed
Open
Opened Apr 05, 2013 by Mike Perry@mikeperry

New Identity hangs on control port activity

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

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#8642