[tor-bugs] #32868 [Core Tor/Tor]: crash: Assertion node->rs->is_possible_guard failed in compute_weighted_bandwidths at

[Tor Bug Tracker & Wiki]

#32868: crash:  Assertion node->rs->is_possible_guard failed in
compute_weighted_bandwidths at
------------------------------+------------------------------------
 Reporter:  toralf            |          Owner:  (none)
     Type:  defect            |         Status:  new
 Priority:  High              |      Milestone:  Tor: 0.4.2.x-final
Component:  Core Tor/Tor      |        Version:  Tor: 0.4.2.5
 Severity:  Normal            |     Resolution:
 Keywords:  regression crash  |  Actual Points:
Parent ID:                    |         Points:
 Reviewer:                    |        Sponsor:
------------------------------+------------------------------------

Comment (by nickm):

 Okay, after a few hours of searching through the code I still don't know
 what's going on.

 We can only reach the assertion failure when a routerstatus entry in the
 consensus we're using has a guardfraction set on a node that is not in
 fact is_possible_guard.

 But whenever we're parsing a consensus, we only set has_guardfraction when
 is_possible_guard is true.

 At first I thought that the issue here might that we were looking at a
 vote instead of a consensus, and I searched for a long time for a way that
 this non-authority relay might be downloading votes and getting confused
 about how to treat them.  I couldn't find such a way.

 But instead, we could be clearing routerstatus_t.is_possible_guard after
 it was first set.  But I can't find a place where we do that on a live
 routerstatus either.

 There is probably something I'm missing here. I'll keep looking.

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