[vim/vim] Vim 9 timers broken on Solaris (Issue #10647)

Matt Wozniski

unread,

Jul 1, 2022, 3:07:24 PM7/1/22

to vim/vim, Subscribed

Steps to reproduce

Run vim --clean on a Solaris machine

Observe that an E1286: Could not set timeout error occurs.
On some machines I saw E1286: Could not set timeout: Insufficient privileges.
On others I got E1286: Could not set timeout: Not owner instead.

Expected behaviour

Vim starts with no error messages.

Version of Vim

9.0.9

Environment

Oracle Solaris 11.3 SPARC

Logs and stack traces

Truss output shows:

timer_create(4, 0xFFFFFFFF7FFFBE58, 0x1005C5754) Err#1 EPERM [proc_clock_highres]

which indicates that the error is coming from [this line](https://github.com/vim/vim/blob/abd56da30bae4a5c6c20b9363ccae12f7b126026/src/os_unix.c#L8321).

The root cause seems to be that `CLOCK_MONOTONIC` on Solaris is defined as an alias for `CLOCK_HIGHRES`:
```c
sys/time_impl.h:#define CLOCK_MONOTONIC         4       /* high resolution monotonic clock */
sys/time_impl.h:#define CLOCK_HIGHRES           CLOCK_MONOTONIC         /* alternate name */

and the CLOCK_HIGHRES timer requires superuser privileges with timer_create:

ERRORS
       The timer_create() function will fail if:
...
       EPERM     The specified clock ID, clock_id, is CLOCK_HIGHRES and the
                 {PRIV_PROC_CLOCK_HIGHRES} is not asserted in the effective
                 set of the calling process.

The configure script only attempts to link a program using timer_create before deciding to set HAVE_TIMER_CREATE=1, so it doesn't notice that it links successfully but fails with a runtime error unless run as a superuser.

We should fall back to using setitimer on Solaris instead (or possibly use timer_create with a different clock than CLOCK_HIGHRES). As a quick hack, this diff gets things working:

--- a/src/os_unix.c
+++ b/src/os_unix.c
@@ -8248,7 +8248,7 @@
 #endif // USE_XSMP

 #if defined(FEAT_RELTIME) || defined(PROTO)
-# if defined(HAVE_TIMER_CREATE) || defined(PROTO)
+# if (!defined(__sun) && defined(HAVE_TIMER_CREATE)) || defined(PROTO)
 /*
  * Implement timeout with timer_create() and timer_settime().
  */
--- a/src/gui.c
+++ b/src/gui.c
@@ -227,7 +227,7 @@
     int		exit_status;
     pid_t	pid = -1;

-#if defined(FEAT_RELTIME) && defined(HAVE_TIMER_CREATE)
+#if defined(FEAT_RELTIME) && (!defined(__sun) && defined(HAVE_TIMER_CREATE))
     // a timer is not carried forward
     delete_timer();
 #endif

though I suspect there's a cleaner solution.

—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 2, 2022, 6:35:57 AM7/2/22

to vim/vim, Subscribed

> ### Steps to reproduce

>
> Run `vim --clean` on a Solaris machine
>
> Observe that an `E1286: Could not set timeout` error occurs.

> On some machines I saw `E1286: Could not set timeout: Insufficient privileges`.

> On others I got `E1286: Could not set timeout: Not owner` instead.
>

> ### Expected behaviour

>
> Vim starts with no error messages.
>

> ### Version of Vim
>
> 9.0.9
>
> ### Environment
>
> Oracle Solaris 11.3 SPARC
>
> ### Logs and stack traces
>
> ```shell

> Truss output shows:
>
> timer_create(4, 0xFFFFFFFF7FFFBE58, 0x1005C5754) Err#1 EPERM [proc_clock_highres]
>
> which indicates that the error is coming from [this line](https://github.com/vim/vim/blob/abd56da30bae4a5c6c20b9363ccae12f7b126026/src/os_unix.c#L8321).

Oh great, another Solaris quirck. It has timer_create() but it doesn't
work the way one expects.

> The root cause seems to be that `CLOCK_MONOTONIC` on Solaris is defined as an alias for `CLOCK_HIGHRES`:
> ```c
> sys/time_impl.h:#define CLOCK_MONOTONIC 4 /* high resolution monotonic clock */
> sys/time_impl.h:#define CLOCK_HIGHRES CLOCK_MONOTONIC /* alternate name */
> ```
>
> and the `CLOCK_HIGHRES` timer requires superuser privileges with `timer_create`:
> ```
> ERRORS
> The timer_create() function will fail if:
> ...
> EPERM The specified clock ID, clock_id, is CLOCK_HIGHRES and the
> {PRIV_PROC_CLOCK_HIGHRES} is not asserted in the effective
> set of the calling process.
> ```
>

> The configure script only attempts to link a program using `timer_create` before deciding to set `HAVE_TIMER_CREATE=1`, so it doesn't notice that it links successfully but fails with a runtime error unless run as a superuser.
>
> We should fall back to using `setitimer` on Solaris instead (or possibly use `timer_create` with a different clock than `CLOCK_HIGHRES`). As a quick hack, this diff gets things working:
> ```diff

> --- a/src/os_unix.c
> +++ b/src/os_unix.c
> @@ -8248,7 +8248,7 @@
> #endif // USE_XSMP
>
> #if defined(FEAT_RELTIME) || defined(PROTO)
> -# if defined(HAVE_TIMER_CREATE) || defined(PROTO)
> +# if (!defined(__sun) && defined(HAVE_TIMER_CREATE)) || defined(PROTO)
> /*
> * Implement timeout with timer_create() and timer_settime().
> */
> --- a/src/gui.c
> +++ b/src/gui.c
> @@ -227,7 +227,7 @@
> int exit_status;
> pid_t pid = -1;
>
> -#if defined(FEAT_RELTIME) && defined(HAVE_TIMER_CREATE)
> +#if defined(FEAT_RELTIME) && (!defined(__sun) && defined(HAVE_TIMER_CREATE))
> // a timer is not carried forward
> delete_timer();
> #endif
> ```
>
> though I suspect there's a cleaner solution.

We can make the configure check not only link but also run the program.

An alternative is to handle it at runtime: include both the code for
timer_create() and setitimer(), and fall back to the latter when the
first fails.

Since this system should be rare, using the configure check looks like a
better solution.

I'll make a patch, please try it out and reopen the issue if it doesn't
work. Check src/auto/config.log for what happened then.

--
Micro$oft: where do you want to go today?
Linux: where do you want to go tomorrow?
FreeBSD: are you guys coming, or what?

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 2, 2022, 6:41:29 AM7/2/22

to vim/vim, Subscribed

Closed #10647 as completed via f2ce76a.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Matt Wozniski

unread,

Jul 5, 2022, 1:38:48 PM7/5/22

to vim/vim, Subscribed

The patch does work. Thanks for the quick fix!

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Ørjan Malde

unread,

Jul 6, 2022, 6:56:49 AM7/6/22

to vim/vim, Subscribed

This change introduces running a test program with autoconf which breaks cross-compilation...

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 6, 2022, 7:42:19 AM7/6/22

to vim/vim, Subscribed

> This change introduces running a test program with autoconf which
> breaks cross-compilation...

Can you suggest how to do this? autoconf syntax is so complicate, it's
very easy to get it wrong. I suppose it can be done with
AC_CACHE_CHECK().

--
Creating the world with Emacs: M-x let-there-be-light
Creating the world with Vim: :make world

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

—

Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Ørjan Malde

unread,

Jul 6, 2022, 8:16:26 AM7/6/22

to vim/vim, Subscribed

Considering this is an exception case I think a simple ifdef for solaris would be the better solution, alternatively a --with/--enable-timer-create that overrides the test perhaps?

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 6, 2022, 8:32:17 AM7/6/22

to vim...@googlegroups.com, Ørjan Malde

> Considering this is an exception case I think a simple ifdef for
> solaris would be the better solution, alternatively a
> --with/--enable-timer-create that overrides the test perhaps?

I would like to keep this consistent with other checks that need to be
handle for cross-compiling. An extra argument would suggest we can't
detect it with autoconf.

--
hundred-and-one symptoms of being an internet addict:
59. Your wife says communication is important in a marriage...so you buy
another computer and install a second phone line so the two of you can
chat.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\

shak5009

unread,

Jul 17, 2022, 11:32:40 AM7/17/22

to vim/vim, Subscribed

Considering this is an exception case I think a simple ifdef for solaris would be the better solution, alternatively a --with/--enable-timer-create that overrides the test perhaps?

I second that.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Lucinda May Phipps

unread,

Jul 23, 2022, 6:03:19 PM7/23/22

to vim/vim, Subscribed

or do it like e.g. vim_cv_getcwd_broken

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Bram Moolenaar

unread,

Jul 24, 2022, 5:15:59 PM7/24/22

to vim/vim, Subscribed

Patch 9.0.0065 should take care of it.

—
Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.

Reply all

Reply to author

Forward