Project

General

Profile

Actions

Bug #17516

open

forking in a ractor causes Ruby to crash

Added by pkmuldoon (Phil Muldoon) 7 months ago. Updated 7 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) 7 months ago

ruby --version

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

Actions #3

Updated by pkmuldoon (Phil Muldoon) 7 months ago

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

Updated by shyouhei (Shyouhei Urabe) 7 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) 7 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