#21415: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed. -----------------------------+------------------------------------ Reporter: cypherpunks | Owner: nickm Type: defect | Status: needs_review Priority: Medium | Milestone: Tor: 0.3.0.x-final Component: Core Tor/Tor | Version: Tor: 0.3.0.3-alpha Severity: Normal | Resolution: Keywords: review-group-16 | Actual Points: Parent ID: | Points: Reviewer: asn | Sponsor: -----------------------------+------------------------------------
Comment (by teor): Replying to [comment:15 nickm]: > Either that, or just adding 1 to num_primary? Circuits can be up to 8 hops long in pathological cases: Having only 2 primary guards with descriptors fails in the scenario where we pick one guard as the exit, and the other as the middle. Having only 3 primary guards with descriptors fails in the scenario where we cannibalise a circuit, and one guard is the exit, and the others are middles. Having only 3 to (max_intro_points + 2) = 12 primary guards with descriptors fails in the scenario where a client fails to connect to an intro point, and so it extends to the next intro point repeatedly, up to 10 intro points. Of course, we're only allowed to send 8 RELAY_EARLY cells, so this is bounded by the maximum path length. Really, we need to check that we have path_length primary guards with descriptors available, or if we don't know the path length at this point, max_path_length. And we should BUG out if the actual path length is greater than this. > And in this case, should we leave the BUG() check in for now? Oh gosh yes! -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21415#comment:16> 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