[tor-bugs] #25316 [Core Tor/Tor]: Assertion failure in scale_active_circuits

[Tor Bug Tracker & Wiki]

#25316: Assertion failure in scale_active_circuits
-----------------------------+------------------------------------
 Reporter:  Logforme         |          Owner:  (none)
     Type:  defect           |         Status:  new
 Priority:  High             |      Milestone:  Tor: 0.3.3.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.3.2.9
 Severity:  Major            |     Resolution:
 Keywords:  crash, must-033  |  Actual Points:
Parent ID:                   |         Points:  0.5
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------

Comment (by dgoulet):

 Fun one...

 I can only see this assert() being triggered if we added twice the same
 ewma circ policy to the active circuit queue. So in the loop, the first
 pass would change the `last_adjusted_tick` and the second pass, the assert
 would be triggered. The only way to do that would be to have called
 `notify_circ_active()` on an already active circuit for which I can't find
 a way how that would be possible....

 We can't have an entry `last_adjusted_tick` in the policy active circuit
 pqueue that wasn't synchronized with the
 `active_circuit_pqueue_last_recalibrated` value. This is done in
 `add_cell_ewma()` which adds the ewma circuit data to the active list and
 just before does:

 {{{
 last_adjusted_tick = active_circuit_pqueue_last_recalibrated
 }}}

 We can't end up in `scale_active_circuits()` for a circuit that is *not*
 in the active queue because of the assert at the end of
 `ewma_notify_xmit_cells()` which makes sure that we've xmit a cell on a
 active circuit of the policy:

 {{{
   tmp = pop_first_cell_ewma(pol);
   tor_assert(tmp == cell_ewma);
   add_cell_ewma(pol, cell_ewma);
 }}}

 Confusing.....

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