#24977: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN)) -------------------------------------------------+------------------------- Reporter: asn | Owner: asn Type: defect | Status: | needs_revision 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: -------------------------------------------------+------------------------- Changes (by asn):
* status: merge_ready => needs_revision Comment: Replying to [comment:19 nickm]: > I think this might actually be a bugfix on 0.3.4, not on 0.3.2: 0.3.4 changed the way that we call the dirvote calculation code when we did #25937. Could that be the cause of this? > Hmm, I don't think so. Because also the backtrace from comment:8 is based on `Tor 0.3.3.5-rc` and represents the bug fixed by the branch. I'll look into this anyway. > As for the patch itself: Is it possible for us to have this recalculation get _scheduled_ in update_current_time, but actually executed inside a mainloop_event? Or does it hurt us to have other stuff called in between those points? The problem there is that update_current_time already does too much: I'd rather keep our callgraph simple, and make tiny-fast functions like this _never_ have a slow-complex case. Yes, I think this is possible. I will try to make it so that `update_current_time()` sets a flag if needed, and then we actually do the computations as part of the HS subsystem. -- Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24977#comment:20> 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