prefork() flushed rb_stdout and rb_stderr, which are the main Ractor's IOs.
From another Ractor that takes the write_lock of an IO the Ractor does not
own. When a main Ractor thread holds it (any thread logging to $stdout will
do), the spawning Ractor's only thread sleeps on the mutex and
rb_check_deadlock, which only looks at the Ractor's own threads, raises
"No live threads left. Deadlock?" (fatal) from Kernel#spawn/system/popen.
Use rb_ractor_stdout()/rb_ractor_stderr() so each Ractor flushes its own.
[Bug #22434]
A thread that is waiting for the fork lock when another thread forks
exists only in the parent, but on macOS the child's copy of the lock
still counts it. After the child unlocks its copy,
pthread_rwlock_destroy() and pthread_rwlock_init() fail with EBUSY, so
the child aborts with
"[BUG] pthread_rwlock_destroy: Resource busy (EBUSY)". Lookup threads
wait for the lock whenever a fork holds it, so a process that resolves
names in background threads while it forks loses a child now and then.
Reset the child's copy by assigning PTHREAD_RWLOCK_INITIALIZER, as
rb_internal_thread_event_hooks_rw_lock_atfork() does for its lock, and
do not unlock it first. With a waiter counted, macOS's unlock enters the
kernel to wake it, and the state that leaves behind for the lock's
address survives the assignment, so a later waiter in the child can
sleep forever although no thread holds the lock. FreeBSD already skipped
the unlock in the child (dc8c382266), and on glibc the child's unlock
does not release the write lock anyway.
[Bug #22445]
A getaddrinfo thread calls getaddrinfo(3) inside rb_thread_prevent_fork,
but on glibc its thread exit takes the resolver configuration lock again
after the thread has released the fork lock. A fork that lands then
leaves the child with that lock held, and every later name lookup in the
child blocks forever. getnameinfo(3) attaches the same resolver state,
even for a name in /etc/hosts, and its thread ran outside
rb_thread_prevent_fork altogether.
Make the lookup threads joinable and have fork join any that may still
be exiting. As a lookup thread finishes, still inside
rb_thread_prevent_fork, it swaps itself into a single slot with an
atomic exchange and joins the thread it displaced, which has usually
exited by then, and rb_thread_acquire_fork_lock joins whatever is left
in the slot. Once lookups settle, at most one finished thread is left
unjoined. The slot holds pthread_t as a pointer, with NULL for empty,
which assumes pthread_t is scalar and never 0.
getnameinfo threads now run within rb_thread_prevent_fork and register
as they exit, as getaddrinfo threads do, and where getnameinfo runs
without a helper thread it is called within rb_thread_prevent_fork too.
So fork also waits for a reverse lookup in progress, as it already did
for a forward one. raddrinfo_pthread_create now always creates joinable
threads, which drops its pthread_detach fallback for platforms without
pthread_attr_setdetachstate.
The slot is kept across fork, so every fork path that keeps running
Ruby code has to take the fork lock. On the BSDs, Process.daemon forks
with daemon(3) and did not take it, so the daemon would inherit the
registered thread, and its next fork would abort in pthread_join with
ESRCH. Take and release the fork lock around daemon(3) as rb_fork_ruby
does. daemon(3) can fail in the child as well as in the parent, so
compare pids to tell which process returned.
[Bug #22406]
These still held String and Array lengths and indices in long, or cast them to long. rb_len_t is still long everywhere, so the generated code does not change.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
USE_SPAWNV needs spawnv without a working fork, which only Windows has since OS/2 support was removed. The non-Windows proc_spawn_cmd_internal and proc_spawn_sh were never compiled, and the Windows proc_spawn_cmd_internal macro was unused because proc_spawn_cmd calls rb_w32_uaspawn_flags directly.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
win32/Makefile.sub and the mingw part of configure.ac already define HAVE_FCNTL_H, HAVE_SPAWNV and HAVE_TIMES, and leave HAVE_SYS_IOCTL_H undefined.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
They are readonly virtual variables backed by per-thread/per-process
state, but user boxes cached the first read in the box gvar_tbl. The
cache stores a clone, and cloning Process::Status does not copy the
wrapped struct, so $? after Kernel#system or IO.popen returned an
uninitialized status, and $$ returned the parent's pid in a forked
child. Bypass the cache like $&, $', and friends.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The clock belongs to the native thread that reads it. An M:N Ruby thread
moves between native threads, so two reads taken from one Ruby thread can
come from different native threads and the later one can be smaller.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The documentation says that Process::Status.wait sets the thread-local
variable $? when there are child processes, but it never does.
rb_process_status_wait does not call rb_last_status_set, and $? is left
untouched:
$? # => nil
Process.spawn('cat /nop') # => 4996
Process::Status.wait # => #<Process::Status: pid 4996 exit 1>
$? # => nil
The existing example showed this as well: the pid displayed for $?
(1155508) did not match the pid of the returned status (1155880),
contradicting the surrounding text.
Since $? is never set, the "does not set thread-local variable $?"
note in the no-child-process case is now redundant and has been folded
into the general description.
The Range Marshal compat dumper would allocate
an Object with no size information, hence get a 32B slot
with enough space for 2 ivars, then insert 3 ivars causing
it to spill.
This isn't a big problem, but somewhat shows that the interface
isn't WVA aware.
By introducing `rb_class_allocate_instance_capa` we can directly
allocate an object with enough room.
The decoration gems are loaded lazily on the first error display, which
in a pre-forking server happens after fork in each child. That loads
their code outside copy-on-write shared memory and busts method caches
at runtime when they prepend Exception#detailed_message.
Process.warmup, called before the first fork by such servers, now loads
them eagerly so the prepended decorators land in shared memory and the
cache invalidation happens during boot.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Track explicit lengths while parsing command strings and comparing the
current directory. This avoids relying on Ruby string terminators and
makes separators in the generated argument buffer explicit.
BSD/OS was discontinued in 2003 and the bsdi* target has been
unbuildable for decades. This also removes the BROKEN_SETREUID and
BROKEN_SETREGID fallbacks in process.c, which no other platform
ever defined.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Set RUBY_TYPED_THREAD_SAFE_FREE on TypedData types whose dfree function
is trivially safe, and only frees its own memory
Types not yet marked as THREAD_SAFE_FREE:
- id2ref_tbl_type: sets the process-global id2ref_tbl to NULL.
- mutex_data_type: unlinks itself from another thread's keeping_mutexes list.
- autoload_data_type: deletes nodes from a shared intrusive list.
- autoload_const_type: deletes itself from a shared list.
- rb_cont_data_type: mutates the shared fiber pool and the global first_jit_cont list.
- rb_fiber_data_type: delegates to cont_free.
- FiberPoolDataType: mutates shared fiber pool free-lists.
- ractor_data_type: reconfigures global VM event-hook flags and call caches.
- exported_object_registry: frees a global table under the VM lock.
- rb_box_data_type (Box::Entry): unlinks classext from other live class and module objects.
- box_ext_cleanup_type: dereferences another String object and calls unlink.
- monitor_data_type: uses the default free, so the flag has no effect.
Co-authored-by: Luke Gruber <luke.gruber@shopify.com>
In many place ALLOC_V / ALLOCV_N is used as a safer `alloca`,
and to behave like stack memory, `ALLOCV` does scan its buffer
for references using `rb_gc_mark_locations`.
The problem is that it's quite slow, and in many cases, the
temporary buffer is known not to contain any references.
e.g. `ALLOCV_N(uint32_t, buf0, len)` can't possibly contain references,
as the element size is too small.
[Bug #17516]
`fork(2)` only leave the calling thread alive in the child.
Because of this forking from the non-main ractor can easily
leave the VM in a corrupted state.
It may be possible in the future to carefully allow forking from non-main
Ractor, but shot term it's preferable to add this restriction.
`extra_fd` was leaked if `fd_set_cloexec` fails -- I can't think of any
chance of that happening here, but just in case.
Coverity Scan found this issue.
So that it doesn't get included in the generated binaries for builds
that don't support loading shared GC modules
Co-Authored-By: Peter Zhu <peter@peterzhu.ca>
John Hawthorn