[tor-bugs] #24502 [Core Tor/Tor]: scheduler_release_channel: Non-fatal assertion

Tor Bug Tracker & Wiki blackhole at torproject.org
Mon Dec 4 19:52:38 UTC 2017


#24502: scheduler_release_channel: Non-fatal assertion
-----------------------------------+------------------------------------
 Reporter:  toralf                 |          Owner:  (none)
     Type:  defect                 |         Status:  needs_review
 Priority:  Low                    |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor           |        Version:  Tor: 0.3.2.6-alpha
 Severity:  Normal                 |     Resolution:
 Keywords:  tor-sched, regression  |  Actual Points:
Parent ID:                         |         Points:
 Reviewer:                         |        Sponsor:
-----------------------------------+------------------------------------
Changes (by dgoulet):

 * keywords:  tor-sched => tor-sched, regression
 * status:  needs_information => needs_review
 * priority:  High => Low


Comment:

 Thanks toralf!

 Bottom line here is that a release on a channel has been done by
 `connection_or_about_to_close()` meaning the channel's connection was
 closed in error state. This seems to be coming from the libevent main
 loop, most likely the `write_event` of the connection.

 I think what happened is that the channel was in pending state in the
 scheduler, it got into the first condition `if
 (socket_can_write(&socket_table, chan)) {` but then because the channel
 wasn't opened, we moved to the next channel.

 This had two consequences. First, the channel scheduler state is kept at
 `PENDING` but it is not put back in the channel pending list. Second,
 because it is still in that state, `scheduler_release_channel()` triggered
 that bug but at least clean it up properly. A `PENDING` state for a
 channel implies that it *has* to be in the pending list.

 The KIST scheduler has 4 conditions and each of them should end with
 setting the channel scheduler state to reflect what has been done with it.

 The condition I outlined above is really the only place I can find where
 we fail to update the state properly. It has been introduced with
 `dcabf801e52` (0.3.2.4-alpha). Fortunately, this is harmless but annoying.

 Branch: `bug24502_032_01`

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


More information about the tor-bugs mailing list