Bug #1872
closed
[ruby_1_8] Kernel#system doesn't work in forked process
Description
=begin
OS 環境に依存している気もしないではないですが，
例えば次のような例が hang-up します．
$ ruby -e 'Process.fork{p system("ls")}'
Linux 2.6.15, glibc 2.3.3 における
ruby 1.8.8dev (2009-08-03 revision 24370) です．
configure オプションは --enable-pthread だけを与えています．
rb_f_system() 中の fork までは完了しており，
子プロセスは生成されてはいるものの，
生成直後に固まってしまっているようです．
親プロセスについては，子プロセスの ID を受け取り，
素直に動作して rb_syswait() に入っているように見受けられます．
なお，上記の例で system の代りに exec とした場合には
問題なく動作します．
=end
Updated by kazuhiko (Kazuhiko Shiozaki) over 15 years ago
=begin
Mandriva 2009.1 (glibc-2.9-0.20081113.5.1mnb2)では再現しませんでしたが、
Debian Ecth (libc6 2.3.6.ds1-13etch9) の環境で再現しました。
リビジョンを遡っていくと、 r23268 以降、発生する（ことがある）ようです。
* eval.c (rb_thread_start_timer): guard condition was inverted. [ruby-dev:38319]
=end
Updated by nagai (Hidetoshi Nagai) over 15 years ago
=begin
永井@知能．九工大です．
From: "U.Nakamura" usa@garbagecollect.jp
Subject: [ruby-dev:39040] Re: [Bug #1872] [ruby_1_8] Kernel#system doesn't work in forked process
Date: Fri, 7 Aug 2009 21:22:11 +0900
Message-ID: 20090807211400.F038.C613B076@garbagecollect.jp
POSIX threadはよくわからないのですが、つらつら考えてみたとこ
ろ、fork前にtimer threadを止めて、fork後に親子双方でまたtimer
threadを動かせばいいんじゃないかという気がしてきました。
手元には環境がないのでかずひこさんに以下のパッチを試してもら
ったところ、いちおう動くようになるみたいです。
私の環境ではダメでした．
パッチの適用前はゴミとして残るプロセス＋スレッドが一つでしたが，
パッチの適用後は六つになりました．(^_^;
永井 秀利 (nagai@ai.kyutech.ac.jp)
九州工業大学 大学院情報工学研究院 知能情報工学研究系 知能情報メディア部門
=end
Updated by kazuhiko (Kazuhiko Shiozaki) over 15 years ago
=begin
Mandriva 2009.1 (glibc-2.9-0.20081113.5.1mnb2)では再現しませんでしたが、
上記の環境でも、何百回と試してみると、2-5%程度の確率で失敗しました。
で、この環境でもなかむら(う)さん提案のパッチをあてると、失敗しなくなりました。
nadokaが--daemonで動かなかったりquickmlがささったりするのは困るので、
とりあえず--disable-pthreadでビルドして回避しています。
また、ruby-trunk (r.24372)ではどちらの環境でも再現しませんでした。
かずひこ
=end
Updated by usa (Usaku NAKAMURA) over 15 years ago
=begin
こんにちは、なかむら(う)です。
In message "[ruby-dev:39039] [Bug #1872] [ruby_1_8] Kernel#system doesn't work in forked process"
on Aug.07,2009 20:09:44, redmine@ruby-lang.org wrote:
Mandriva 2009.1 (glibc-2.9-0.20081113.5.1mnb2)では再現しませんでしたが、
Debian Ecth (libc6 2.3.6.ds1-13etch9) の環境で再現しました。
リビジョンを遡っていくと、 r23268 以降、発生する（ことがある）ようです。* eval.c (rb_thread_start_timer): guard condition was inverted. [ruby-dev:38319]
r23268自体は正当な修正なので、要するに該当環境だとtimer thread
がいる時にforkするとまずいということなのでしょう。
POSIX threadはよくわからないのですが、つらつら考えてみたとこ
ろ、fork前にtimer threadを止めて、fork後に親子双方でまたtimer
threadを動かせばいいんじゃないかという気がしてきました。
手元には環境がないのでかずひこさんに以下のパッチを試してもら
ったところ、いちおう動くようになるみたいです。
わかる人や元のコードを書いた人(なかださんかな?)に発想が正しい
か考えてほしいのですが、どんなもんでしょうか...
Index: eval.c
--- eval.c (revision 24389)
+++ eval.c (working copy)
@@ -12485,7 +12485,7 @@ rb_thread_start_timer()
safe_mutex_lock(&time_thread.lock);
if (pthread_create(&time_thread.thread, 0, thread_timer, args) == 0) {
thread_init = 1;
- pthread_atfork(0, 0, rb_thread_stop_timer);
- pthread_atfork(rb_thread_stop_timer, rb_thread_start_timer, rb_thread_start_timer);
pthread_cond_wait(&start, &time_thread.lock);
}
pthread_cleanup_pop(1);
それでは。
--
U.Nakamura usa@garbagecollect.jp
=end
Updated by ujihisa (Tatsuhiro Ujihisa) about 15 years ago
- Status changed from Open to Assigned
- Assignee set to nobu (Nobuyoshi Nakada)
=begin
=end
Updated by naruse (Yui NARUSE) almost 15 years ago
=begin
関連すると推測される Bug #2603 が解決しましたが、こちらは現状どんな感じですか。
あと、永井さんの環境ってディストリビューション何ですか?
まだ再現するようだったら環境を誰かが用意できるように
=end
Updated by nagai (Hidetoshi Nagai) almost 15 years ago
=begin
永井＠知能．九工大です．
このところ手が回ってなくて，追随できてなくてすみません．
From: Yui NARUSE redmine@ruby-lang.org
Subject: [ruby-dev:40123] [Bug #1872] [ruby_1_8] Kernel#system doesn't work in forked process
Date: Fri, 22 Jan 2010 01:43:37 +0900
Message-ID: 4b58843937cbf_8bcebe21d049911@redmine.ruby-lang.org
関連すると推測される Bug #2603 が解決しましたが、こちらは現状どんな感じですか。
試しました．問題は解決したように見えます．
あと、永井さんの環境ってディストリビューション何ですか?
Vine-3.2 ベースです．
かなり古く，サポートもなくなった環境ですが，
諸事情あってそのまま残している代物です．
そんな古いものは知らねぇよという意見もありそうですが，
完全に無視していいほどには古くないと思ってます．
永井 秀利 (nagai@ai.kyutech.ac.jp)
九州工業大学 大学院情報工学研究院 知能情報工学研究系 知能情報メディア部門
=end
Updated by naruse (Yui NARUSE) almost 15 years ago
- Status changed from Assigned to Closed
=begin
確認ありがとうございました。
それではこれは解決とします。
=end