port-sparc64/53296: vim is super-slow (hangs) on sparc64 / select issue

[tobiasu%tmux.org@localhost]

>Number:         53296
>Category:       port-sparc64
>Synopsis:       vim is super-slow (hangs) on sparc64 / select issue
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-sparc64-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu May 17 16:25:00 +0000 2018
>Originator:     Tobias Ulmer
>Release:        8.99.17
>Organization:
>Environment:
NetBSD u60 8.99.17 NetBSD 8.99.17 (GENERIC) #5: Wed May 16 13:48:05 UTC 2018  root@u60:/usr/obj/sys/arch/sparc64/compile/GENERIC sparc64
>Description:
HW: Ultra 60 2x450mhz 2G, plenty fast for what I'm asking it to do.

vim /etc/fstab takes 10 or more seconds display the file.

Cursor movement 'hangs' (feels like using vim over a modem line on the other side of the world). Connection is over local ssh and vi works fine.


Had a look with ktrace. Vim is repeatedly calling select() (~1000+ times) with varying timeout less than 1s. select() returns either 0 or EINVAL.

Patched the kernel to see where EINVAL comes from. It's either because the input struct timeval's tv_usec is already negative or the conversion to timespec produces an integer overflow.

Example: sys___select50: tv={0, -18872}

tv_sec is always 0. tv_usec is suspiciously random.


Had a look into vim's os_unix.c. It's calling select() in RealWaitForChar(), passing in a timeout pointer tvp to a local struct timeval tv;

But no matter how hard I try, gdb insists the value of *tvp is  {0, 0}.  -O2, -O0 make no difference.

I've put in code to make it coredump when tv_usec is != 0 to no avail.

os_unix.c:

6229            if (tvp->tv_usec != 0)
6230                    abort();
6231            ret = select(maxfd + 1, &rfds, &wfds, &efds, tvp);
6232            if (ret < 0)
6233                    abort(); // this hits.

Anyone got an idea how to solve this mystery?





>How-To-Repeat:

>Fix: