#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 asn): Replying to [comment:10 nickm]: > `bug21415_030` is the fix I suggested above, of which asn said: > > > Your fix suggestion seems plausible here, but I'd like some more confidence that we have found the right bug. > > Asn: Based on Teor's logs, do you think this is the right fix? Ugh, I've been digging in the logs for at least an hour trying to verify our theory, but it doesn't seem to apply straightforwardly. Here is the primary guard list from `info.2.log`: {{{ Feb 27 05:21:23.000 [info] entry_guards_update_primary(): Primary entry guards have changed. New primary guard list is: Feb 27 05:21:23.000 [info] entry_guards_update_primary(): 1/3: test004r ($A92594E93FEE5D83D12D977460B1DA47916B28A6) (confirmed) Feb 27 05:21:23.000 [info] entry_guards_update_primary(): 2/3: test005r ($EF23A3601B2234F32EF6673DDCD4ECE6040327B7) (confirmed) Feb 27 05:21:23.000 [info] entry_guards_update_primary(): 3/3: test006r ($3AF6D56A2B57BE95F4D097035473E06109E426D4) }}} Here are guard successes for all the primaries: {{{ Feb 27 05:21:29.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard test004r ($A92594E93FEE5D83D12D977460B1DA47916B28A6) ... Feb 27 05:21:34.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard test005r ($EF23A3601B2234F32EF6673DDCD4ECE6040327B7) ... Feb 27 05:21:34.000 [info] entry_guards_note_guard_success(): Recorded success for primary confirmed guard test006r ($3AF6D56A2B57BE95F4D097035473E06109E426D4) }}} and then here is the assert a few seconds afterwards: {{{ Feb 27 05:21:40.000 [info] choose_good_exit_server_general(): Chose exit server '$A92594E93FEE5D83D12D977460B1DA47916B28A6~test004r at 127.0.0.1' Feb 27 05:21:40.000 [info] extend_info_from_node(): Including Ed25519 ID for $A92594E93FEE5D83D12D977460B1DA47916B28A6~test004r at 127.0.0.1 Feb 27 05:21:40.000 [warn] tor_bug_occurred_(): Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed. (on Tor 0.3.1.0-alpha- dev efa5bbaba07d20d1) [snip] Feb 27 05:21:40.000 [info] select_entry_guard_for_circuit(): Selected primary guard test006r ($3AF6D56A2B57BE95F4D097035473E06109E426D4) for circuit. }}} which I assume was generated because of `test005r` missing a descriptor, since we chose `test004r` (our first primary) as an exit node, and then we ended up choosing `test006r` (our last primary) as the entry node after the assert triggered... But then how come a circuit to `test005r` succeeded just 6 seconds before the assert triggered? Why didnt we get the assert at that point (maybe it was a directory circuit?)? But then how did we get past `entry_guards_have_enough_dir_info_to_build_circuits()`? I don't see `test005r` being marked as unreachable anywhere before that. Could this be called by some bridge weirdness? But then how come it was reproduced in `hs-ipv6` network? Some more digging is required. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/21415#comment:13> 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