julialang / libuv Goto Github PK

Seems this was introduced in 794bfdf, as NULL is documented as a valid result for the variable on that line¹, but that is not handled here.

see JuliaLang/julia#41642 (comment) for reproducer

• Version: julia-uv2-1.44.1
• Platform: linux

Julia version of libuv uses vfork() for uv_spawn() implementation, but contrary to vfork() manpage it manages file descriptors and signal handlers prior to calling exec(). This might work fine with vanilla kernel/libc, but breaks in our environment. We use custom code for accelerated network sockets, which breaks when the child process shares address space with the parent process.

https://github.com/JuliaLang/libuv/blob/julia-uv2-1.44.1/src/unix/process.c#L990

Standard description
       (From POSIX.1) The vfork() function has the same effect as
       fork(2), except that the behavior is undefined if the process
       created by vfork() either modifies any data other than a variable
       of type pid_t used to store the return value from vfork(), or
       returns from the function in which vfork() was called, or calls
       any other function before successfully calling _exit(2) or one of
       the exec(3) family of functions.

change to https://github.com/JuliaLang/libuv/tree/julia-uv2-1.29.1

We briefly block all signals during fork, because unix is often really bad at handling them during this call. However, we're blocking everything, and that's perhaps too much since it means buggy OS code (probably an atfork handler) can get us wedged. For example, I recorded us getting stuck here on my 10.14.6 laptop: Darwin Jameson.local 18.7.0 Darwin Kernel Version 18.7.0: Sun Dec 1 18:59:03 PST 2019; root:xnu-4903.278.19~1/RELEASE_X86_64 x86_64

(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
  * frame #0: 0x00007fff5f80a9e2 libdispatch.dylib`_firehose_task_buffer_init + 32
    frame #1: 0x00007fff5f7ea63d libdispatch.dylib`_dispatch_client_callout + 8
    frame #2: 0x00007fff5f7ebd4b libdispatch.dylib`_dispatch_once_callout + 20
    frame #3: 0x00007fff5f808b77 libdispatch.dylib`voucher_activity_get_metadata_buffer + 100
    frame #4: 0x00007fff5fa44163 libsystem_trace.dylib`_os_trace_init_slow + 94
    frame #5: 0x00007fff5f7ea63d libdispatch.dylib`_dispatch_client_callout + 8
    frame #6: 0x00007fff5f7ebd4b libdispatch.dylib`_dispatch_once_callout + 20
    frame #7: 0x00007fff5fa45f17 libsystem_trace.dylib`os_log_type_enabled + 463
    frame #8: 0x00007fff5deddf00 libnetwork.dylib`nw_path_close_fd + 144

We should probably avoid blocking anything that shouldn't be deferred (esp. SIGILL, SIGABRT, SIGSYS, SIGSEGV, SIGFPE, etc.) although nothing we do (except perhaps avoiding fork altogether by using vfork and/or posix_spawn+VFORK) is going to make this entirely reliable.

Note: prior to this, this had been spewing messages like the following during prior (successful) uv_spawn calls (many times, but it was an earlier process):

2019-12-21 00:01:51.006900-0500 julia-debug[17119:785417] nw_path_close_fd Failed to close guarded necp fd 43 [9: Bad file descriptor]

Hopefully this info helps someone on Google, since this appears to not be an uncommon issue for the past 2 years.

libuv/libuv@master...JuliaLang:julia-uv2-1.39.0

How many of these should/can be upstreamed? It would be good to get to a point where none are needed.

This is a bit of a trivial request, but it'd be nice if compare urls worked using tags:

https://github.com/JuliaLang/libuv/compare/v1.42.0...julia-uv2-1.42.0.patch

The tags here are old: https://github.com/JuliaLang/libuv/tags

Some asserts from 5599b8c are messed up, but I'm not sure on the right way to fix them. There's also

lt-run-tests: src/unix/loop.c:93: uv_loop_delete: Assertion `uv_loop_close(loop) == 0' failed.

from a different test, ref #28.