Opened 7 months ago

Closed 7 months ago

#21035 closed defect (fixed)

Assertion in 0.2.9.8: monotime_coarse_get

Reported by: tmpname0901 Owned by: nickm
Priority: Medium Milestone: Tor: 0.2.9.x-final
Component: Core Tor/Tor Version: Tor: 0.2.9.8
Severity: Normal Keywords: regression
Cc: Actual Points: .1
Parent ID: Points: .2
Reviewer: Sponsor:

Description

Dec 20 02:44:06.000 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) opening log file.
Dec 20 02:44:06.630 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 20 02:44:06.630 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 20 02:44:06.630 [notice] Read configuration file "/etc/tor/torrc".
Dec 20 02:44:06.633 [notice] Based on detected system memory, MaxMemInQueues is set to 6144 MB. You can override this by setting MaxMemInQueues by hand.
Dec 20 02:44:06.634 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 20 02:44:06.634 [notice] Opening OR listener on 46.29.248.238:443
Dec 20 02:44:06.634 [notice] Opening Directory listener on 46.29.248.238:80
Dec 20 02:44:06.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Dec 20 02:44:06.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Dec 20 02:44:06.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Dec 20 02:44:06.000 [err] tor_assertion_failed_(): Bug: src/common/compat_time.c:359: monotime_coarse_get: Assertion r == 0 failed; aborting. (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: Assertion r == 0 failed in monotime_coarse_get at src/common/compat_time.c:359. Stack trace: (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(log_backtrace+0x42) [0x2b9dce1a5222] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(tor_assertion_failed_+0xa3) [0x2b9dce1bd6d3] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(monotime_coarse_get+0x59) [0x2b9dce1a9e59] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(tor_main+0x86) [0x2b9dce099d46] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(main+0x19) [0x2b9dce096b19] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /lib64/libc.so.6(libc_start_main+0xfd) [0x2b9dcf1e6d1d] (on Tor 0.2.9.8 01ab67e38b358ae9)
Dec 20 02:44:06.000 [err] Bug: /usr/bin/tor(+0xada29) [0x2b9dce096a29] (on Tor 0.2.9.8 01ab67e38b358ae9)


Environment: CentOS v6.8, OpenVZ virtualization, confirmed system time is accurate. No problem seen in same environment with Tor v0.2.8.11.

Child Tickets

Change History (16)

comment:1 Changed 7 months ago by tmpname0901

No problem seen with v0.2.8.12 either. FYI.

comment:2 Changed 7 months ago by yawning

  • Priority changed from Very High to Medium
  • Severity changed from Major to Normal

0.2.8.x does not use clock_gettime() IIRC.

Does your kernel not have a functional CLOCK_MONOTONIC_COARSE? CentOS 6.8's should (since Linux 2.6.32; Linux-specific). What is the value of errno at the time of the assert? EINVAL?

comment:3 Changed 7 months ago by tmpname0901

Does your kernel not have a functional CLOCK_MONOTONIC_COARSE?

I can't say. As stated this is running in an OpenVZ container:

# uname -a
Linux torsrvi.snydernet.net 2.6.18-400.el5.028stab117.2 #1 SMP Wed Dec 17 17:19:54 MSK 2014 x86_64 x86_64 x86_64 GNU/Linux

No problems seen with running 0.2.9.8 in other OpenVZ / CentOS v6.8 VPSs. Maybe there is some peculiarity about the configuration of the OpenVZ containers from this VPS vendor?

comment:4 Changed 7 months ago by yawning

2.6.18-400.el5.028stab117.2

That is not a CentOS 6.8 kernel: https://openvz.org/Download/kernel/rhel5/028stab117.2

And kernels that old, will not have CLOCK_MONOTONIC_COARSE.

comment:5 Changed 7 months ago by nickm

  • Keywords regression added

Looks like the right fix here is to probe at startup time to see whether monotonic_coarse works, and if not, use monotonic?

comment:6 Changed 7 months ago by yawning

If we want to support things that predate 2.6.32 then yes. Despite RHEL5 exiting the production phase of it's lifecycle in March next year, the fix here is easy enough to do.

comment:7 Changed 7 months ago by nickm

  • Owner set to nickm
  • Points set to .2
  • Status changed from new to accepted

comment:8 Changed 7 months ago by nickm

  • Actual Points set to .1
  • Status changed from accepted to needs_review

Branch bug21035 in my public repository has a fix here. It could use some review.

Also, tmpname0901, is this something you can test?

comment:9 Changed 7 months ago by tmpname0901

Also, tmpname0901, is this something you can test?

Sure, I can test it.

I'm not very familiar with the Tor repository branches. Can you point me to your repository? Thanks.

comment:10 Changed 7 months ago by nickm

Sure! https://gitweb.torproject.org/nickm/tor.git is the web URL; https://git.torproject.org/nickm/tor.git is the URL that you give to git. The branch is bug20135, which is based on maint-0.2.9.

comment:11 Changed 7 months ago by tmpname0901

Hmmm....

$ git clone -b bug20135 https://git.torproject.org/nickm/tor.git
Cloning into 'tor'...
fatal: Remote branch bug20135 not found in upstream origin

What am I doing wrong here, Nick?

comment:12 Changed 7 months ago by nickm

Oops! "bug21035", not "bug20135".

comment:13 Changed 7 months ago by tmpname0901

Seems to be working.

I did a recursive diff of your branch and the released v0.2.9.8 tarball, and there were a *lot* of differences (3MB patch file). So I applied only your changes to ~/tor/src/common/compat_time.c to the released version to avoid muddying the water with extraneous changes. Rebuilt and all seems to be well.


Dec 21 20:15:36.000 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) opening log file.
Dec 21 20:15:36.704 [notice] Tor 0.2.9.8 (git-01ab67e38b358ae9) running on Linux with Libevent 2.0.22-stable, OpenSSL 1.0.2j and Zlib 1.2.8.
Dec 21 20:15:36.704 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://www.torproject.org/download/download#warning
Dec 21 20:15:36.704 [notice] Read configuration file "/etc/tor/torrc".
Dec 21 20:15:36.707 [notice] Based on detected system memory, MaxMemInQueues is set to 6144 MB. You can override this by setting MaxMemInQueues by hand.
Dec 21 20:15:36.707 [notice] Opening Socks listener on 127.0.0.1:9050
Dec 21 20:15:36.707 [notice] Opening OR listener on 46.29.248.238:443
Dec 21 20:15:36.708 [notice] Opening Directory listener on 46.29.248.238:80
Dec 21 20:15:36.000 [notice] Parsing GEOIP IPv4 file /usr/share/tor/geoip.
Dec 21 20:15:36.000 [notice] Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
Dec 21 20:15:36.000 [notice] Configured to measure statistics. Look for the *-stats files that will first be written to the data directory in 24 hours from now.
Dec 21 20:15:36.000 [notice] Your Tor server's identity key fingerprint is 'Unnamed 7452E7D19ACD2C39DE10C0207032E6BC05DB78F2'
Dec 21 20:15:36.000 [notice] Bootstrapped 0%: Starting
Dec 21 20:15:46.000 [notice] Bootstrapped 80%: Connecting to the Tor network
Dec 21 20:15:46.000 [notice] Self-testing indicates your ORPort is reachable from the outside. Excellent.
Dec 21 20:15:47.000 [notice] Bootstrapped 85%: Finishing handshake with first hop
Dec 21 20:15:47.000 [notice] Bootstrapped 90%: Establishing a Tor circuit
Dec 21 20:15:47.000 [notice] Tor has successfully opened a circuit. Looks like client functionality is working.
Dec 21 20:15:47.000 [notice] Bootstrapped 100%: Done

comment:14 follow-up: Changed 7 months ago by yawning

https://gitweb.torproject.org/nickm/tor.git/commit/?h=bug21035&id=a757f769676cf0a942fb1c909ff4cf469d362d12

This looks ok to me.

Somewhat related, I think the tests will fail to compile on U*IX systems that lack CLOCK_MONOTONIC_COARSE entirely. (test_util.c:test_util_monotonic_time() calls monotime_coarse_get() which is behind a #ifdef).

comment:15 in reply to: ↑ 14 Changed 7 months ago by nickm

Replying to yawning:

Somewhat related, I think the tests will fail to compile on U*IX systems that lack CLOCK_MONOTONIC_COARSE entirely. (test_util.c:test_util_monotonic_time() calls monotime_coarse_get() which is behind a #ifdef).

Ah, but in compat_time.h, we have:

#if defined(MONOTIME_COARSE_FN_IS_DIFFERENT)
void monotime_coarse_get(monotime_coarse_t *out);
 ...
#else
#define monotime_coarse_get monotime_get
 ...
#endif

comment:16 Changed 7 months ago by nickm

  • Resolution set to fixed
  • Status changed from needs_review to closed

(Patch merged to 0.2.9 and forward. Thanks for testing and review!)

Note: See TracTickets for help on using tickets.