#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
_______________________________________________ tor-bugs mailing list tor-bugs@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs