[tor-bugs] #24610 [Core Tor/Tor]: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Dec 14 13:46:21 UTC 2017


#24610: assertion !(status == HS_CLIENT_FETCH_HAVE_DESC) failed
-----------------------------+------------------------------------
 Reporter:  cypherpunks      |          Owner:  (none)
     Type:  defect           |         Status:  new
 Priority:  Medium           |      Milestone:  Tor: 0.3.2.x-final
Component:  Core Tor/Tor     |        Version:  Tor: 0.3.2.1-alpha
 Severity:  Normal           |     Resolution:
 Keywords:  prop224, tor-hs  |  Actual Points:
Parent ID:                   |         Points:
 Reviewer:                   |        Sponsor:
-----------------------------+------------------------------------

Comment (by dgoulet):

 We shouldn't think comment:2 is accurate also. After working on this, a
 simpler edge-case to trigger this became apparent so what you describe is
 really what should be considered as "the problem" of this ticket.

 > The first commit should fix this scenario because now
 can_client_refetch_desc() will return HS_CLIENT_FETCH_PENDING instead of
 HS_CLIENT_FETCH_HAVE_DESC. I wonder if there are any other such weird
 edge-cases this patch won't fix :S

 As you noticed, I left the BUG() there and even added a non fatal assert
 so if this is triggered again, we can investigate more. At least, in both
 cases, the tor client is fine and recovers.

 > Do we have a way to test this fix btw?

 I would love to come up with a test case. It is a bit difficult because we
 kind of need to artificially inject the race in a unit test. I think a
 useful unit test overall would be to make sure we can *NOT* launch 2
 directory requests in parallel for the same service. The
 `can_client_refetch_desc()` is really our safeguard there.

 The other thing we can unit test probably easily is have a pending
 directory request, after set a descriptor usable and call
 `hs_client_dir_info_changed()` to see that we don't get that usable
 descriptor.

 Both seems very doable. In the timeframe of 032 release candidate, dunno
 but definitely short term, this is needed.

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


More information about the tor-bugs mailing list