Project

General

Profile

Actions

Bug #17516

open

forking in a ractor causes Ruby to crash

Added by pkmuldoon (Phil Muldoon) 10 months ago. Updated 10 months ago.

Status:
Open
Priority:
Normal
Assignee:
-
Target version:
-
ruby -v:
ruby 3.0.0p0 (2020-12-25 revision 95aff21468) [x86_64-darwin20]
[ruby-core:101952]

Description

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 -------------------------------------------
=> #
[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]


Files

ruby_2021-01-06-104315_phillip-muldoon-FA588.crash (31.8 KB) ruby_2021-01-06-104315_phillip-muldoon-FA588.crash crash report pkmuldoon (Phil Muldoon), 01/06/2021 11:12 AM

Updated by pkmuldoon (Phil Muldoon) 10 months ago

ruby --version

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

Actions #3

Updated by pkmuldoon (Phil Muldoon) 10 months ago

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

Updated by shyouhei (Shyouhei Urabe) 10 months ago

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

Updated by pkmuldoon (Phil Muldoon) 10 months ago

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:

Actions

Also available in: Atom PDF