#24977: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN)) -------------------------------------------------+------------------------- Reporter: asn | Owner: asn Type: defect | Status: | merge_ready Priority: Medium | Milestone: Tor: | 0.3.4.x-final Component: Core Tor/Tor | Version: Tor: | 0.3.2.1-alpha Severity: Normal | Resolution: Keywords: tor-hs, prop224, | Actual Points: 034-triage-20180328, 034-removed-20180502 | Parent ID: | Points: 1 Reviewer: dgoulet | Sponsor: -------------------------------------------------+-------------------------
Comment (by asn): Replying to [comment:23 dgoulet]: > > Because we recalculate the data in an event loop now, it means other events can trigger the assert() on the hsdir indexes because they would see the consensus being live but the recalculate consensus callback was not yet triggered. For instance, a client request to a .onion will trigger the assert() if done before the recalculation happened because it would consider the consensus live. > > In other words, there is a time gap between "clock jump, now I have a live consensus" and "recalculate conensus data", we'll end up in some desynch state imo. HS is just one big example, there might be more. > Hm, I guess the HS-client example above is indeed a plausible (but unlikely) edge-case. It's worth noting that the example you cited above applies only to the HS client case, whereas I think we covered it for HS services since services basically function based on those callbacks. Of course, there might be other cases around the codebase, which we are not aware of right now ("if a tree falls in a forest and no one is around to hear it..."). Some obvious approaches: a) Fix all the cases by recomputing data immediately when a clock jump is noticed (as per my first branch). This has the negative effect of giving variable time duration to the callback as Nick pointed out. b) Fix the HS client edge-case dgoulet pointed out, by calling `recalculate_consensus_data_callback()` when an HS client tries to connect to an HS. c) Merge Nick's branch and leave the edge-cases open. In the future, we can fix those too as we understand more things about this problem. d) Do more research, try to understand the problem more, and figure out an even better solution if possible... -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24977#comment:24> 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