[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #29500 [Core Tor/Tor]: Broken circuitpadding unittests on appveyor

#29500: Broken circuitpadding unittests on appveyor
-------------------------------------------------+-------------------------
 Reporter:  asn                                  |          Owner:  (none)
     Type:  defect                               |         Status:  new
 Priority:  High                                 |      Milestone:  Tor:
                                                 |  0.4.0.x-final
Component:  Core Tor/Tor                         |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  wtf-pad, tor-relay, tor-cell,        |  Actual Points:
  padding, 041-proposed, 040-must                |
Parent ID:  #28631                               |         Points:
 Reviewer:                                       |        Sponsor:
-------------------------------------------------+-------------------------

Comment (by mikeperry):

 Replying to [comment:11 teor]:
 > Replying to [comment:10 mikeperry]:
 > > However, I have no idea why the rtt test is failing. It almost seems
 like a compiler bug.
 >
 > It's an OS bug:
 >
 https://gitweb.torproject.org/tor.git/tree/src/lib/time/compat_time.c#n543
 > https://www.python.org/dev/peps/pep-0418/#windows-
 queryperformancecounter
 >
 > Which tor works around by pretending that no time has elapsed:
 >
 https://gitweb.torproject.org/tor.git/tree/src/lib/time/compat_time.c#n175
 >
 > More generally, there is no guarantee that the monotonic clock will have
 increased by at least 1000 nanoseconds between monotime_init() and
 circpad_estimate_circ_rtt_on_received()'s call to
 monotime_absolute_usec(). A non-increasing value is more likely when the
 monotonic clock's resolution is in milliseconds: two calls can easily
 return the same value.
 >
 > But the circuitpadding code assumes that monotime_absolute_usec() is
 always greater than zero.

 But wait, how is this OS bug still happening even though I mocked monotime
 and monotime_coarse in test_circuitpad_rtt()? I set the mocked absolute
 time to be 1000 nsec, so
 monotime_absolute_usec() should be returning 1 in
 circpad_estimate_circ_rtt_on_received().

 Is the problem maybe that sometimes the nsec_per_tick_numer value is very
 high on some appveyor instances? Would using a larger initial mocked time
 than 1000 nsec solve the issue for this test?

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/29500#comment:14>
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