Segmentation fault error when upgrading nio4r from 2.5.9 to 2.6.0

[albertski]

After upgrading nio4r, I get the following error on CircleCi:

/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/puma-4.3.12/lib/puma/reactor.rb:136: [BUG] Segmentation fault at 0x00000000000002

-- Control frame information -----------------------------------------------
c:0004 p:---- s:0020 e:000019 CFUNC  :select
c:0003 p:0021 s:0015 e:000014 METHOD /home/circleci/project/vendor/bundle/ruby/3.0.0/gems/puma-4.3.12/lib/puma/reactor.rb:136
c:0002 p:0018 s:0007 e:000006 BLOCK  /home/circleci/project/vendor/bundle/ruby/3.0.0/gems/puma-4.3.12/lib/puma/reactor.rb:313 [FINISH]
c:0001 p:---- s:0003 e:000002 (none) [FINISH]

-- Ruby level backtrace information ----------------------------------------
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/puma-4.3.12/lib/puma/reactor.rb:313:in `block in run_in_thread'
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/puma-4.3.12/lib/puma/reactor.rb:136:in `run_internal'
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/puma-4.3.12/lib/puma/reactor.rb:136:in `select'

-- Machine register context ------------------------------------------------
 RIP: 0x00007f9021f246a5 RBP: 0x0000000000000000 RSP: 0x00007f9013efe6c0
 RAX: 0x00007f900c00b280 RBX: 0x0000000000000240 RCX: 0x00007f900c00b290
 RDX: 0x0000000000000001 RDI: 0x00007f901815b010 RSI: 0x00007f900c00b290
  R8: 0x00007f902708d6d0  R9: 0x00007f8ff5c048d8 R10: 0x00000000000056a8
 R11: 0x0000000000002948 R12: 0x00000000fffffffe R13: 0x0000000000000002
 R14: 0x0000000000000013 R15: 0x00007f901815b010 EFL: 0x0000000000010206

-- C level backtrace information -------------------------------------------
/usr/local/bin/ruby(rb_print_backtrace+0x11) [0x55d2c22f1cb2] vm_dump.c:758
/usr/local/bin/ruby(rb_vm_bugreport) vm_dump.c:998
/usr/local/bin/ruby(rb_bug_for_fatal_signal+0xec) [0x55d2c239a54c] error.c:786
/usr/local/bin/ruby(sigsegv+0x4d) [0x55d2c224823d] signal.c:963
/lib/x86_64-linux-gnu/libpthread.so.0(__restore_rt+0x0) [0x7f9027a7e3c0]
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(NIO_Selector_monitor_callback+0x15) [0x7f9021f246a5] selector.c:567
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(NIO_Selector_monitor_callback) (null):0
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(ev_invoke_pending+0x56) [0x7f9021f1c5e6] ../libev/ev.c:3765
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(ev_run+0x7fe) [0x7f9021f2064e] ../libev/ev.c:4253
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(NIO_Selector_run+0x36) [0x7f9021f22c27] selector.c:476
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(NIO_Selector_select_synchronized) selector.c:431
/usr/local/bin/ruby(rb_ensure+0x114) [0x55d2c20fa094] eval.c:1162
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(NIO_Selector_synchronize+0xd8) [0x7f9021f233b8] selector.c:301
/home/circleci/project/vendor/bundle/ruby/3.0.0/gems/nio4r-2.6.0/lib/nio4r_ext.so(NIO_Selector_select) selector.c:409
/usr/local/bin/ruby(vm_call_cfunc_with_frame+0x11b) [0x55d2c22ca41b] vm_insnhelper.c:2928
/usr/local/bin/ruby(vm_sendish+0xe) [0x55d2c22e0afb] vm_insnhelper.c:4529
/usr/local/bin/ruby(vm_exec_core) insns.def:789
/usr/local/bin/ruby(rb_vm_exec+0x18e) [0x55d2c22d4f4e] vm.c:2163
/usr/local/bin/ruby(rb_vm_invoke_proc+0x33) [0x55d2c22daea3] vm.c:1485
/usr/local/bin/ruby(thread_do_start_proc+0x26d) [0x55d2c228cc1d] thread.c:736
/usr/local/bin/ruby(thread_do_start+0x14) [0x55d2c228f9b4] thread.c:755
/usr/local/bin/ruby(thread_start_func_2) thread.c:834
/usr/local/bin/ruby(rb_native_cond_initialize+0x0) [0x55d2c229030b] thread_pthread.c:994
/usr/local/bin/ruby(register_cached_thread_and_wait) thread_pthread.c:1046
/usr/local/bin/ruby(thread_start_func_1) thread_pthread.c:1001
/lib/x86_64-linux-gnu/libpthread.so.0(0x9609) [0x7f9027a72609]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x43) [0x7f9027778293]

I'm using nio4r on a Rails 6 project using Ruby 3.0.3. Puma is a 4.3.12. Would you have any insight why this is happening?

[ioquatix]

Here is the diff, let me take a look at what might have changed: v2.5.9...v2.6.0

[ioquatix]

nio4r/ext/nio4r/selector.c

Lines 563 to 567 in d9682cf

	void NIO_Selector_monitor_callback(struct ev_loop *ev_loop, struct ev_io *io, int revents)
	{
	struct NIO_Monitor *monitor_data = (struct NIO_Monitor *)io->data;
	struct NIO_Selector *selector = monitor_data->selector;
	VALUE monitor = monitor_data->self;

[ioquatix]

Do you mind updating the version of Ruby to 3.2.2 and the version of Puma to check if the issue still exists?

[ioquatix]

There was a slight behavioural change here: v2.5.9...v2.6.0#diff-bce1c1b7cb30fa881da1ad53c13dcff2903d61028874c65f6354b2258f17a0edL100-R112

The io that gets stored is the result of to_io - I can revert this. It's the only thing I can think may affect the code.

[ioquatix]

Are you able to test with this branch? #306

[albertski]

Thanks @ioquatix. I confirm that by upgrading Puma to 6.0.2, the issue went away. Also, I confirm #306 fixed the issue too (with Puma 4.3.12). Thanks for the quick fix.

[ioquatix]

Released in v2.6.1.