From: xtkoba+ruby@... Date: 2021-06-17T01:30:26+00:00 Subject: [ruby-core:104325] [Ruby master Bug#17993] Ruby process stuck in rb_sigwait_sleep Issue #17993 has been updated by xtkoba (Tee KOBAYASHI). I doubt if installation of `SIGCHLD` handler is relevant. It is true that the handler for `SIGCHLD` is changed in `Webserver::Start()` (`src/kudu/server/webserver.cc`): ```c sighandler_t sig_chld = signal(SIGCHLD, SIG_DFL); /* ... */ signal(SIGCHLD, sig_chld); ``` but as the previous handler is restored it should not affect the subsequent `#system`. Furthermore, this is in the server side, not client. if #note-1 were the point, a workaround would be as follows: ```ruby # ... TestFFI.build_client(ARGV[0]) Signal.trap(:CHLD, "DEFAULT") # added system "true" ``` ---------------------------------------- Bug #17993: Ruby process stuck in rb_sigwait_sleep https://bugs.ruby-lang.org/issues/17993#change-92547 * Author: cout (Paul Brannan) * Status: Open * Priority: Normal * ruby -v: ruby 2.7.3p183 (2021-04-05 revision 6847ee089d) [x86_64-linux-gnu] * Backport: 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN ---------------------------------------- I have a very simple client for kudu (https://kudu.apache.org/) implement as a wrapper that I invoke with FFI. After creating a kudu client with `KuduClientBuilder::Build()`, subsequent calls to `system` cause the ruby interpreter to block indefinitely. It is unclear to me whether the fault is in the ruby interpreter, in my wrapper code, or in kudu. The wrapper looks like this: ``` #include #include extern "C" { int build_client(char const * addr) { ::kudu::client::sp::shared_ptr<::kudu::client::KuduClient> client; auto status = ::kudu::client::KuduClientBuilder() .add_master_server_addr(addr) .Build(&client); return status.ok(); } } ``` And the ruby script looks like this: ``` require 'ffi' module TestFFI extend ::FFI::Library ffi_lib './libtest_ffi.so' attach_function :build_client, [ :strptr ], :int end TestFFI.build_client(ARGV[0]) system("true"); ``` The backtrace for the main thread looks like this: ``` #0 0x00007ff93fbe3811 in ppoll () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007ff9411030e0 in rb_sigwait_sleep (th=th@entry=0x1261440, sigwait_fd=sigwait_fd@entry=3, rel=rel@entry=0x0) at /data/ruby-2.7.3/hrtime.h:148 #2 0x00007ff941104488 in native_sleep (th=0x1261440, rel=0x0) at /data/ruby-2.7.3/thread_pthread.c:2099 #3 0x00007ff94110708e in rb_thread_sleep_interruptible () at /data/ruby-2.7.3/thread.c:1329 #4 0x00007ff94106d945 in waitpid_sleep (x=x@entry=140729366950784) at /data/ruby-2.7.3/process.c:1151 #5 0x00007ff940f8f32c in rb_ensure (b_proc=b_proc@entry=0x7ff94106d930 , data1=data1@entry=140729366950784, e_proc=e_proc@entry=0x7ff94106d8e0 , data2=data2@entry=140729366950784) at /data/ruby-2.7.3/eval.c:1129 #6 0x00007ff941075389 in rb_f_system (argc=, argv=, _=) at /data/ruby-2.7.3/process.c:4557 #7 0x00007ff941138f53 in vm_call_cfunc_with_frame (empty_kw_splat=, cd=, calling=, reg_cfp=, ec=) at /data/ruby-2.7.3/vm_insnhelper.c:2514 #8 vm_call_cfunc (ec=0x1261a50, reg_cfp=0x7ff94168ffa0, calling=, cd=0x156d680) at /data/ruby-2.7.3/vm_insnhelper.c:2539 #9 0x00007ff9411459ac in vm_sendish (method_explorer=, block_handler=, cd=, reg_cfp=, ec=) at /data/ruby-2.7.3/vm_insnhelper.c:4023 #10 vm_exec_core (ec=0x7ffe1bed31b8, initial=1) at insns.def:801 #11 0x00007ff94114bc1f in rb_vm_exec (ec=0x1261a50, mjit_enable_p=1) at /data/ruby-2.7.3/vm.c:1929 #12 0x00007ff940f8bbd0 in rb_ec_exec_node (ec=ec@entry=0x1261a50, n=n@entry=0x13ce5c8) at /data/ruby-2.7.3/eval.c:278 #13 0x00007ff940f91078 in ruby_run_node (n=0x13ce5c8) at /data/ruby-2.7.3/eval.c:336 #14 0x00000000004009df in main (argc=, argv=) at /data/ruby-2.7.3/main.c:50 ``` Tested with ruby 2.7.3p183 and kudu 1.10.0-cdh6.3.0 on Ubuntu 16.04. Everything works as expected on ruby 2.5. I have not tried any other combinations of ruby or kudu. -- https://bugs.ruby-lang.org/ Unsubscribe: