Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Trac Trac
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Service Desk
    • Milestones
  • Monitor
    • Monitor
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value stream
  • Wiki
    • Wiki
  • Activity
  • Create a new issue
  • Issue Boards
Collapse sidebar
  • Legacy
  • TracTrac
  • Issues
  • #3037

Closed (moved)
(moved)
Open
Created Apr 28, 2011 by Roger Dingledine@arma

Internal checks to detect client streams/circuits whose sock request vanished

Tor has a cycle for handling streams, where it attaches the stream to a circuit, gives up after a while, attaches it to another, etc.

Tor also has a timeout after which it hangs up on the socks connection, and some logic to notice that a socks connection has hung up so it should cancel streams.

Long ago, it was quite common for me to see the "keep trying" cycle continue even after the socks request had vanished. Those were bugs.

I haven't seen them so much recently, but it would be smart to add some logic to check the consistency of "for each thing we're trying to handle, is there still a connection around that's asking us to handle it." If we had that logic, it might help catch the root cause of #2983 (moved).

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking