Tests which access the X selections hang if something is asserting ownership

[jamessan]

• nvim --version: HEAD
• Vim (version: NA) behaves differently?
• Operating system/version: Debian sid

Actual behaviour

If a program is currently asserting ownership of an X selection used by a test, the test will hang due to xsel/xclip not exiting.

Expected behaviour

The test completes successfully, regardless of whether the selection is asserted when the test runs.

Steps to reproduce using nvim -u NORC

• Double-click on a word in a terminal, thus asserting the PRIMARY selection.
• make functionaltest TEST_FILE=test/functional/legacy/eval_spec.lua

I ran into this while investigating the QB test failures for #4841, although I'm not entirely sure that it's related since I wouldn't expect any selections to be asserted there.

[bfredl]

IMO the tests should not change the user clipboards at all (no "save, change and then restore" does not work in general), unless maybe some env flag that could be set in travis and qb where we have control over it.
One can easily switch to a "fake" private clipboard in lua tests using
execute('let &rtp = "test/functional/fixtures,".&rtp')
right after clear().

[jamessan]

At least one of those tests (viml_system_spec.lua) is explicitly testing handling of child processes with a specific behavior (exhibited by xclip). Maybe a simple test program that exhibits the same behavior would be a better solution there.

[justinmk]

Maybe a simple test program that exhibits the same behavior would be a better solution there.

Here is a snippet: #4798 (comment)

[jamessan]

I'm not sure the sleep is as relevant for this scenario is just having the child process not explicitly close its stdout/stderr handles.

[justinmk]

Can this be closed?

[jamessan]

I don't think so. The viml_system_spec test is still using xclip, which may encounter this issue.

Even if that wasn't a problem, I think having a small test program that exhibits the problem is better than relying on the environment having xclip installed, since it ensures we're testing the problem consistently and doesn't mess with the user's environment.

[justinmk]

Fixed by #4798

[jamessan]

This shouldn't have been closed. There's still a test that's invoking xclip, which both messes with the user's selection and prevents the tests from exiting.

[justinmk]

We could wrap that test in a timeout

[jamessan]

The test itself completes. The test runner doesn't, because xclip is still running. For example, the last test run I did has been sitting here for the past 12 hours:

●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●◌
2052 successes / 0 failures / 0 errors / 4 pending : 124.10955 seconds

Pending → .../src/github.com/neovim/test/functional/core/job_spec.lua @ 531
jobs will only emit the "exit" event after "stdout" and "stderr"

Pending → ...github.com/neovim/test/functional/provider/ruby_spec.lua @ 20
Cannot find the neovim RubyGem. Try :CheckHealth

Pending → ...thub.com/neovim/test/functional/terminal/cursor_spec.lua @ 63
terminal cursor with number column is positioned correctly when focused

Pending → ...src/github.com/neovim/test/functional/viml/lang_spec.lua @ 11
viml parses `<SID>` with turkish locale
...src/github.com/neovim/test/functional/viml/lang_spec.lua:11: Locale tr_TR.UTF-8 not supported

14126 pts/5    S+     0:00      \_ make functionaltest
14139 pts/5    S+     0:00          \_ ninja -C build functionaltest
14140 pts/5    Z+     0:00              \_ [sh] <defunct>
15557 pts/5    S+     0:00 xclip -i -selection clipboard

Killing xclip lets it clean up.

[blueyed]

I agree that we should have a specialized program to test the behavior, and not messing with the clipboard data (#4900 (comment)).

I came here, since the fix / workaround here (-loops 1) causes the test(s) to fail with a clipboard manager (copyq) for me:

[  FAILED  ] test/functional/eval/system_spec.lua @ 382: system() with a program that doesn't close stdout will exit properly after passing input
test/functional/eval/system_spec.lua:384: Expected objects to be the same.
Passed in:
(string) 'Error: target STRING not available
'
Expected:
(string) 'clip-data'

stack traceback:
	test/functional/eval/system_spec.lua:384: in function <test/functional/eval/system_spec.lua:382>

[  FAILED  ] test/functional/eval/system_spec.lua @ 566: systemlist() with a program that doesn't close stdout will exit properly after passing input
test/functional/eval/system_spec.lua:569: Expected objects to be the same.
Passed in:
(table) {
 *[1] = 'Error: target STRING not available' }
Expected:
(table) {
 *[1] = 'clip'
  [2] = 'data' }

stack traceback:
	test/functional/eval/system_spec.lua:569: in function <test/functional/eval/system_spec.lua:566>


 2 FAILED TESTS
-- Output to stderr:

CMake Error at …/Vcs/neovim/cmake/RunTests.cmake:56 (message):
  functional tests failed with error: 1


FAILED: CMakeFiles/functionaltest