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

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#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 teor):

 Replying to [comment:10 mikeperry]:
 > Replying to [comment:9 asn]:
 > > Mike, wrt the `test_circuitpadding_tokens()` test, could it be another
 case where the test actually schedules legit padding because of a state
 transition or something and it might trigger or might not depending on how
 the timing of the test goes?  Like the one from #29122?
 >
 > Yes, that does seem likely for the tokens test. In fact, I think this
 should fix it, if we could reproduce:
 > https://github.com/mikeperry-
 tor/tor/commit/b61cd3709be53dd0aee55111dc0c29b882c31cc6

 The 0.4.0 and master builds all failed due to this bug after #29599 was
 merged.

 But only the "Image: Visual Studio 2017; Environment:
 target=x86_64-w64-mingw32..." jobs failed, so it might be timing-
 sensitive. Or the OS bug might happen reliably on Windows Server 2016.

 You can remote desktop to the build machine if you want:
 https://www.appveyor.com/docs/how-to/rdp-to-build-worker/

 It will be easier to set up if you use your own appveyor account, not
 Tor's.

 > 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.

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