[tor-bugs] #21415 [Core Tor/Tor]: tor_bug_occurred_: Bug: src/or/entrynodes.c:1845: select_entry_guard_for_circuit: Non-fatal assertion !(!guard_has_descriptor(guard)) failed.

[Tor Bug Tracker & Wiki]

#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:  assigned
 Priority:  Medium        |      Milestone:  Tor: 0.3.0.x-final
Component:  Core Tor/Tor  |        Version:  Tor: 0.3.0.3-alpha
 Severity:  Normal        |     Resolution:
 Keywords:                |  Actual Points:
Parent ID:                |         Points:
 Reviewer:                |        Sponsor:
--------------------------+------------------------------------

Comment (by asn):

 Replying to [comment:4 nickm]:
 > The warning here seems to be here, in
 select_entry_guard_for_circuit()...
 > {{{
 >   SMARTLIST_FOREACH_BEGIN(gs->primary_entry_guards, entry_guard_t *,
 guard) {
 >     entry_guard_consider_retry(guard);
 >     if (! entry_guard_obeys_restriction(guard, rst))
 >       continue;
 >     if (guard->is_reachable != GUARD_REACHABLE_NO) {
 >       if (need_descriptor && BUG(!guard_has_descriptor(guard))) {
 >         continue;
 >       }
 > }}}
 >
 > And this, in turn, looks like a problem with our 21242 code. We're not
 supposed to be calling select_entry_guard_for_circuit() with
 need_descriptor set while
 guard_selection_have_enough_dir_info_to_build_circuits() is false, right?
 >
 > Though hm, that function only checks to make sure that the first
 num_primary possibly reachable guards all have descriptors.  If enough of
 them seem down, there's a decent chance that we'll turn to a position
 where we might have to update our 'can build circuits' flag.
 >
 > If that's so, then the right fix here is probably either to remove the
 BUG guard on the check.

 Hmm, it's a interesting point, that
 `guard_selection_have_enough_dir_info_to_build_circuits()` only checks for
 descriptors of reachable guards.

 This means that if one of our primary guards was considered unreachable
 (see `Proxy Client` errors in comment:2)  we would still get past
 `guard_selection_have_enough_dir_info_to_build_circuits()` even if we
 don't have its descriptor. Then after a few minutes, when that primary
 guard gets marked for retry, and we still dont have its descriptor, we
 could potentially trigger the non-fatal assert.

 I'm still a bit hazy with the code flow here, and whether the above is a
 possible, or if there are any alternative problems here.

 Your fix suggestion seems plausible here, but I'd like some more
 confidence that we have found the right bug. BTW note that the bug
 reporter is reproducing this bug using obfs4 '''bridges''', so IIUC we
 first call `select_entry_guard_for_circuit()` with
 `need_descriptor==False` (to get its descriptor) and then again with
 `need_descriptor==True` (to actually do traffic).

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