[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))
#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:
-------------------------------------------------+-------------------------
Changes (by asn):
* status: needs_revision => merge_ready
Comment:
Replying to [comment:20 asn]:
> 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.
>
Hm. I checked the branch from #25937 and I don't think it's related to
this bug. This bug has been around for ever, but it started being visible
now because we require a live consensus for some HSv3 functions to work
properly. Hence, when we fetch a consensus with a skewed clock and wrongly
consider it non-live, the relevant HSv3 functions also work badly. Our
patch now basically re-runs those functions after the clock gets fixed.
> > 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.
I implemented the above approach in my branch `bug24977`. You can also see
the relevant PR here: https://github.com/torproject/tor/pull/124
Please compare the approach of `bug24977` with the one from
`bug24977_dev`. I think the one using callbacks indeed looks better.
Not sure if this bug fix warrants a backport, it seems to be quite rare
because it requires a skewed clock to occur. I'd vote for no, but let me
know if you have a different opinion and I can prepare branches.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/24977#comment:21>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs