From: "mame (Yusuke Endoh)" <mame@...>
Date: 2012-04-23T22:29:12+09:00
Subject: [ruby-core:44549] [ruby-trunk - Bug #6341][Feedback] SIGSEGV: Thread.new { fork { GC.start } }.join


Issue #6341 has been updated by mame (Yusuke Endoh).

Status changed from Open to Feedback
Priority changed from High to Low

Hello,

NetBSD is not supported currently.  A patch is welcome.


The following is just my guess.

There is a constraint in POSIX that only async-signal-safe functions
can be called after fork.  In many systems which conforms to POSIX,
this constraint is more or less relaxed.  In recent NetBSD, however,
I heard that the constraint is real.  To comply with it, I have no
idea but prohibiting Kernel#fork in NetBSD (as well as windows).

Again, this is just my guess.  I'm sorry if my guess is wrong.

-- 
Yusuke Endoh <mame@tsg.ne.jp>
----------------------------------------
Bug #6341: SIGSEGV: Thread.new { fork { GC.start } }.join
https://bugs.ruby-lang.org/issues/6341#change-26101

Author: rudolf (r stu3)
Status: Feedback
Priority: Low
Assignee: 
Category: core
Target version: 
ruby -v: ruby 1.9.3p196 (2012-04-21) [x86_64-netbsd6.0.]


When running ruby (ruby-lang.org) test suite, I am able to provoke a segfault using a test from bootstraptest/test_thread.rb:
begin
  Thread.new { fork { GC.start } }.join
  pid, status = Process.wait2
  $result = status.success? ? :ok : :ng
rescue NotImplementedError
  $result = :ok
end

It is easy to provoke the problem with this command launched in shell (1-20 times until the problem shows):
$ ruby -e "Thread.new { fork { GC.start } }.join"

Environment:
- NetBSD-6.0_BETA amd64, from 2012/04/21
- ruby_1_9_3 branch, revision 35416 (I've also tried trunk and it has similar problem)
- 8 GB RAM, a lot of free memory, dual-core CPU
- gcc version 4.5.3 (NetBSD nb2 20110806)

Backtrace and "bt full" is available in the attached gdb_session.txt file.


-- 
http://bugs.ruby-lang.org/