Luvit aborts when redirecting output to file

[joerg-krause]

Since commit 84218f2 redirecting the output of luvit aborts. This bad commit was found using git bisect.

Test file hello.lua:

print("hello world")

Lua and Luvit 2.14.2 are working fine:

$ lua hello.lua > hello.txt && cat hello.txt
hello world

$ ../luvi/build/luvi -- . hello.lua > hello.txt && cat hello.txt
hello world

$ ../luvi/build/luvi -- . --version
luvit version: 2.14.2
luvi version: v2.9.3-11-g17c1c9b
rex version: 8.37 2015-04-28
libuv version: 1.29.0
ssl version: OpenSSL 1.1.1b  26 Feb 2019, lua-openssl 0.7.5-2

... whereas Luvit 2.16.0 aborts:

$ ../luvi/build/luvi -- . hello.lua > hello.txt && cat hello.txt
Aborted (core dumped)

$ ../luvi/build/luvi -- . --version
luvit version: 2.16.0
luvi version: v2.9.3-11-g17c1c9b
rex version: 8.37 2015-04-28
libuv version: 1.29.0
ssl version: OpenSSL 1.1.1b  26 Feb 2019, lua-openssl 0.7.5-2

[squeek502]

My first guess is that this is related to luvit/luv#437, but I need to look into it more to be sure exactly how.

Some slightly interesting things to note:

• Adding print(handle) at the top of the uv.walk loop in Luvit's init.lua fixes the abort and the redirected output looks like:

hello world
uv_tty_t: 0x09cee0e0
uv_pipe_t: 0x09cee1a8
uv_tty_t: 0x09cee250
uv_check_t: 0x09cee330
uv_idle_t: 0x09cee370
uv_signal_t: 0x09cfe488

• Adding a print call after the uv.walk throws a pretty-print.lua:308: bad argument #1 to 'write' (Expected uv_stream userdata) error as described in Fix uv.shutdown cb being called when canceled luv#414, since the uv.walk closes stdout.

[squeek502]

Minimal reproduction with just luv:

local uv = require('luv')

local stdout
if uv.guess_handle(1) == 'tty' then
  stdout = assert(uv.new_tty(1, false))
else
  stdout = assert(uv.new_pipe(false))
  uv.pipe_open(stdout, 1)
end

stdout:write("hello world\n")
uv.run()

stdout:shutdown()
uv.run()

When redirecting output to a file, uv.guess_handle() returns "file" so a pipe is created. The uv.shutdown call is what causes the abort--using close instead avoids the abort. Also, removing the first uv.run() and only calling uv.run() once avoids the abort as well, so it might be some type of double-shutdown thing happening.

EDIT: gdb stacktrace:

Program received signal SIGABRT, Aborted.
0xb7fdabd1 in __kernel_vsyscall ()
(gdb) up
#1  0xb7db9ea9 in __GI_raise (sig=6) at ../sysdeps/unix/sysv/linux/raise.c:54
54	../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) up
#2  0xb7dbb407 in __GI_abort () at abort.c:89
89	abort.c: No such file or directory.
(gdb) up
#3  0xb7d53fc1 in uv__io_poll (loop=0xb7d78f98, timeout=-1)
    at /home/ryan/Documents/luv/deps/libuv/src/unix/linux-core.c:253
253	        abort();
(gdb) up
#4  0xb7d3e95b in uv_run (loop=0xb7d78f98, mode=UV_RUN_DEFAULT)
    at /home/ryan/Documents/luv/deps/libuv/src/unix/core.c:373
373	    uv__io_poll(loop, timeout);
(gdb) up
#5  0xb7d20ac7 in luv_run (L=0xb7d6c1c0)
    at /home/ryan/Documents/luv/src/loop.c:34
34	  int ret = uv_run(luv_loop(L), (uv_run_mode)mode);

[squeek502]

Possibly a LibUV bug when calling uv_shutdown on a file stream. Even more minimal recreation, not even using stdout and not even writing anything:

local uv = require('luv')

local fd = assert(uv.fs_open('test.txt', 'w', tonumber('644', 8)))
local pipe = assert(uv.new_pipe())
assert(uv.pipe_open(pipe, fd))
pipe:shutdown()
uv.run()

LibUV only tests uv_shutdown on TCP streams as far as I can tell. Will try to recreate it with plain LibUV next.

[squeek502]

Was able to reproduce it with libuv: libuv/libuv#2658