Bug #17516: forking in a ractor causes Ruby to crash

• Status: Assigned
• Assignee: ko1 (Koichi Sasada)
• Target version: -
• ruby -v: ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
• Backport: 2.5: UNKNOWN, 2.6: UNKNOWN, 2.7: UNKNOWN, 3.0: UNKNOWN

[pkmuldoon (Phil Muldoon)]

I just want to point out, there's absolutely no reason to do this, but

r = Ractor.new do
Process.fork()
end

Will cause:

internal:ractor:267: warning: Ractor is experimental, and the behavior may change in future versions of Ruby! Also there are many implementation issues.
[BUG] rb_thread_terminate_all: called by child thread (0x0000700004ddca40, 0x00007f981b567ee0)
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]

-- Crash Report log information --------------------------------------------
See Crash Report log file under the one of following:
* ~/Library/Logs/DiagnosticReports
* /Library/Logs/DiagnosticReports
for more details.
Don't forget to include the above Crash Report log file in bug reports.

-- Control frame information -----------------------------------------------
c:0001 p:---- s:0003 e:000002 (none) [FINISH]

-- C level backtrace information -------------------------------------------
=> #<Ractor:#3 (pry):5 terminated>
[4] pry(main)> /Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_vm_bugreport+0x6cf) [0x103084d1f]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug_without_die+0x206) [0x102e9e2b6]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_bug+0x71) [0x103091e6b]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_thread_terminate_all+0x329) [0x10301e5b9]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ractor_terminate_all+0xa3) [0x102f8acc3]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(rb_ec_cleanup+0x229) [0x102ea9299]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(ruby_stop+0x9) [0x102ea9509]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_2+0x8ce) [0x103027fce]
/Users/phillipmuldoon/.rubies/ruby-3.0.0/bin/ruby(thread_start_func_1+0x10d) [0x10302753d]
/usr/lib/system/libsystem_pthread.dylib(_pthread_start+0xe0) [0x7fff20382950]

[pkmuldoon (Phil Muldoon)]

ruby --version

ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]

[pkmuldoon (Phil Muldoon)]

• File ruby_2021-01-06-104315_phillip-muldoon-FA588.crash ruby_2021-01-06-104315_phillip-muldoon-FA588.crash added

[pkmuldoon (Phil Muldoon)]

• ruby -v set to ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]

[shyouhei (Shyouhei Urabe)]

This must be a bug.

Besides there is a technical difficulty to fork a multi-Ractor program (or, there is a technical difficulty to combine pthread and fork in general). I didn’t think we should allow such operation.

Further reading: this looong rationale written in https://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_atfork.html

[pkmuldoon (Phil Muldoon)]

I'm wondering if we can limit Process calls in the ractor as we do for accessing out of band variables? I've not had a chance to attach GDB to the Ruby VM yet (I have to compile Ruby with -O0 -g3 for things to be clear).

BTW I'm not suggesting anyone every do that code snippet in the original post! It's somewhat of a theoretical testcase. But the Ruby interpreter shouldn't crash either :thinking face:

[hsbt (Hiroshi SHIBATA)]

• Status changed from Open to Assigned
• Assignee set to ko1 (Koichi Sasada)

[jeremyevans0 (Jeremy Evans)]

I submitted a pull request to disallow fork from inside a ractor: https://github.com/ruby/ruby/pull/8283