aboutsummaryrefslogtreecommitdiff
path: root/changes/bug40684
diff options
context:
space:
mode:
authorNick Mathewson <nickm@torproject.org>2022-10-13 13:40:10 -0400
committerNick Mathewson <nickm@torproject.org>2022-10-13 13:40:10 -0400
commite531d4d1b9753e80b56a28805b01c014a1fe5d51 (patch)
treeb941665cd6ef168a34b3b8b966d2fec1f9477dc8 /changes/bug40684
parentd52a5f2181f44ddb387e9d9a40523054a1f80bff (diff)
downloadtor-e531d4d1b9753e80b56a28805b01c014a1fe5d51.tar.gz
tor-e531d4d1b9753e80b56a28805b01c014a1fe5d51.zip
Fix a completely wrong calculation in mach monotime_init_internal()
Bug 1: We were purporting to calculate milliseconds per tick, when we *should* have been computing ticks per millisecond. Bug 2: Instead of computing either one of those, we were _actually_ computing femtoseconds per tick. These two bugs covered for one another on x86 hardware, where 1 tick == 1 nanosecond. But on M1 OSX, 1 tick is about 41 nanoseconds, causing surprising results. Fixes bug 40684; bugfix on 0.3.3.1-alpha.
Diffstat (limited to 'changes/bug40684')
-rw-r--r--changes/bug406846
1 files changed, 6 insertions, 0 deletions
diff --git a/changes/bug40684 b/changes/bug40684
new file mode 100644
index 0000000000..8c751ede2c
--- /dev/null
+++ b/changes/bug40684
@@ -0,0 +1,6 @@
+ o Major bugfixes (OSX):
+ - Fix coarse-time computation on Apple platforms (like Mac M1) where
+ the Mach absolute time ticks do not correspond directly to
+ nanoseconds. Previously, we computed our shift value wrong, which
+ led us to give incorrect timing results.
+ Fixes bug 40684; bugfix on 0.3.3.1-alpha.