Bug #1872: [ruby_1_8] Kernel#system doesn't work in forked process

• Status: Closed
• Assignee: nobu (Nobuyoshi Nakada)
• Target version: Ruby 1.8.8
• ruby -v: ruby 1.8.8dev (2009-08-03 revision 24370) [i686-linux]

[nagai (Hidetoshi Nagai)]

=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

[kazuhiko (Kazuhiko Shiozaki)]

=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

[nagai (Hidetoshi Nagai)]

=begin
永井@知能．九工大です．

From: "U.Nakamura" [e-mail]
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: [e-mail]

POSIX threadはよくわからないのですが、つらつら考えてみたとこ
ろ、fork前にtimer threadを止めて、fork後に親子双方でまたtimer
threadを動かせばいいんじゃないかという気がしてきました。
手元には環境がないのでかずひこさんに以下のパッチを試してもら
ったところ、いちおう動くようになるみたいです。

私の環境ではダメでした．
パッチの適用前はゴミとして残るプロセス＋スレッドが一つでしたが，
パッチの適用後は六つになりました．(^_^;

永井 秀利 ([e-mail])
九州工業大学 大学院情報工学研究院 知能情報工学研究系 知能情報メディア部門

=end

[kazuhiko (Kazuhiko Shiozaki)]

=begin

Mandriva 2009.1 (glibc-2.9-0.20081113.5.1mnb2)では再現しませんでしたが、
上記の環境でも、何百回と試してみると、2-5%程度の確率で失敗しました。
で、この環境でもなかむら(う)さん提案のパッチをあてると、失敗しなくなりました。

nadokaが--daemonで動かなかったりquickmlがささったりするのは困るので、
とりあえず--disable-pthreadでビルドして回避しています。

また、ruby-trunk (r.24372)ではどちらの環境でも再現しませんでした。

かずひこ

=end

[usa (Usaku NAKAMURA)]

=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, [e-mail] 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 [e-mail]

=end

[ujihisa (Tatsuhiro Ujihisa)]

• Status changed from Open to Assigned
• Assignee set to nobu (Nobuyoshi Nakada)

=begin

=end

[naruse (Yui NARUSE)]

=begin
関連すると推測される Bug #2603 が解決しましたが、こちらは現状どんな感じですか。
あと、永井さんの環境ってディストリビューション何ですか?
まだ再現するようだったら環境を誰かが用意できるように
=end

[nagai (Hidetoshi Nagai)]

=begin
永井＠知能．九工大です．

このところ手が回ってなくて，追随できてなくてすみません．

From: Yui NARUSE [e-mail]
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: [e-mail]

関連すると推測される Bug #2603 が解決しましたが、こちらは現状どんな感じですか。

試しました．問題は解決したように見えます．

あと、永井さんの環境ってディストリビューション何ですか?

Vine-3.2 ベースです．
かなり古く，サポートもなくなった環境ですが，
諸事情あってそのまま残している代物です．

そんな古いものは知らねぇよという意見もありそうですが，
完全に無視していいほどには古くないと思ってます．

永井 秀利 ([e-mail])
九州工業大学 大学院情報工学研究院 知能情報工学研究系 知能情報メディア部門

=end

[naruse (Yui NARUSE)]

• Status changed from Assigned to Closed

=begin
確認ありがとうございました。
それではこれは解決とします。
=end