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
  • #21142

Closed (moved)
(moved)
Open
Created Jan 05, 2017 by George Kadianakis@asn

prop271: circuits_pending_other_guards not properly maintained

Hello,

I've been doing various tests to prop271 by using it with tor browser.

I started digging more into circuit_find_circuits_to_upgrade_from_guard_wait() and particularly the circuits_pending_other_guards smartlist to understand better how this feature works in little-t-tor.

While inspecting the elements of circuits_pending_other_guards I noticed that some of those circuits were zombies that were already freed, probably because they were closed but not removed from the smartlist.

The only time we change membership of that list is in circuit_set_state():

 if (circ->state == CIRCUIT_STATE_GUARD_WAIT) {
    smartlist_remove(circuits_pending_other_guards, circ);
  }
  if (state == CIRCUIT_STATE_GUARD_WAIT) {
    smartlist_add(circuits_pending_other_guards, circ);
  }

We should probably consider removing circuits from that list when they marked for close as well, so that the list does not stay permanently populated. Also see how membership in the similar smartlist circuits_pending_chans is maintained.

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