[tor-bugs] #24977 [Core Tor/Tor]: Non-fatal assertion !(tor_mem_is_zero((const char*)node->hsdir_index->fetch, DIGEST256_LEN))

[Tor Bug Tracker & Wiki]

#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