[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