[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #32868 [Core Tor/Tor]: crash: Assertion node->rs->is_possible_guard failed in compute_weighted_bandwidths at
#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@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs