Bug #4157: test_pty で、たまに出る Failure

• Status: Closed
• Assignee: metanest (Makoto Kishimoto)
• Target version: -
• ruby -v: -
• Backport: 2.3: UNKNOWN, 2.4: UNKNOWN, 2.5: UNKNOWN

[metanest (Makoto Kishimoto)]

=begin
amd64 FreeBSD8 でも #4121 が起きることがあるのですが、
while で $ while make test-all TESTS="test_pty.rb" ; do : ; done のように実行していると、他の Failure がたまに起きます。
以下のように、どれも、期待した文字列の代わりに nil が返っています。

1. Failure:
   test_argv0(TestPTY) [/export/home/ksmakoto/ruby-git/test/test_pty.rb:45]:
   <"bar\r\n"> expected but was
   .

2. Failure:
   test_commandline(TestPTY) [/export/home/ksmakoto/ruby-git/test/test_pty.rb:36]:
   <"foo\r\n"> expected but was
   .

3. Failure:
   test_spawn_with_block(TestPTY) [/export/home/ksmakoto/ruby-git/test/test_pty.rb:26]:
   <"b\r\n"> expected but was
   .

4. Failure:
   test_spawn_without_block(TestPTY) [/export/home/ksmakoto/ruby-git/test/test_pty.rb:19]:
   <"a\r\n"> expected but was
   .
   =end

[metanest (Makoto Kishimoto)]

=begin
%ruby で CPU 数が影響してるのかも、とコメントをいただいたので、cpuset -l 0 で実行して
みたところ、#4121 が確実に起きるようになり、（test_getpty_nonexistent をコメントアウトして
実行すると）逆にこの報告の Failure は出なくなりました。4 コアマシンです。
=end

[metanest (Makoto Kishimoto)]

=begin
手元でビルド可能な最古の trunk の r21509 でも起きました。
=end

[naruse (Yui NARUSE)]

• Status changed from Open to Assigned
• Assignee set to metanest (Makoto Kishimoto)

もうこれ再現しないと思うんですがいかがでしょうが

[metanest (Makoto Kishimoto)]

trunk の r32231 で再現できませんでした

[nahi (Hiroshi Nakamura)]

• Status changed from Assigned to Closed
• Assignee changed from metanest (Makoto Kishimoto) to naruse (Yui NARUSE)
• Target version set to 1.9.3

ありがとうございます。修正済み扱いで閉じますので、再現したらご連絡をお願いします。

[metanest (Makoto Kishimoto)]

すいません。かなり頻度は低くなっているようなのですが、while make test-all TESTS="test_pty.rb" ; do : ; done をしばらく（100回ほどやってみると最長で3分ほど）動かしてみるとやはり trunk（r32037）でも起きました
ステータスそのままでいいと思いますが、一応報告します

[kosaki (Motohiro KOSAKI)]

• Status changed from Closed to Assigned
• Assignee changed from naruse (Yui NARUSE) to metanest (Makoto Kishimoto)

いやいや、再現するならreopenしましょうよ。closeされたチケットを追っかけてくれる人が
この世にいるだろうか（反語）
というわけで Kishimotoさんアサインでリザレクトします。

[metanest (Makoto Kishimoto)]

がさごそやっていてちょっと気になったのですが、

PTY.getpty の rdoc には、疑似端末のマスターデバイスにつながった r と w
のオブジェクトが IO と書かれていますが、コードのほうは File を生成して
います。

[metanest (Makoto Kishimoto)]

きしもとです

PTY についてですが、さらにいくつか気になったので、中間まとめを作ります。

・（るりま）1.9.2 で protect_signal が削除されたことに対応していない
・（るりま）1.9.2 (？) で SIGCHLD の捕捉をおこなわなくなったことに
　対応していない
・PTY.check を第二引数 raise=true で実行すると、子プロセスが実行中でも
　PTY::ChildExited が発生する（これは別件でバグ？）

「テストがたまに fail」の原因は、ktrace してみると read の時点で読めて
ない、ということ以外、皆目掴めないのですが、PTY.open と Kernel#spawn
を組み合わせて同じことをやった場合は問題が出ないようですし、Kernel#spawn
の新しい機能を使えば PTY#getpty（PTY#spawn）と同じことは PTY.open と
組み合わせて簡単にできるので、PTY#getpty は deprecated として、
2.0（か 1.9.5 ？）で削除してしまう、ことを提案します。

[akr (Akira Tanaka)]

• ruby -v changed from ruby 1.9.3dev (2010-12-14 trunk 30206) [x86_64-freebsd8.2] to -

2011年10月12日9:03 KISHIMOTO, Makoto [e-mail]:

「テストがたまに fail」の原因は、ktrace してみると read の時点で読めて
ない、ということ以外、皆目掴めないのですが、PTY.open と Kernel#spawn
を組み合わせて同じことをやった場合は問題が出ないようですし、Kernel#spawn
の新しい機能を使えば PTY#getpty（PTY#spawn）と同じことは PTY.open と
組み合わせて簡単にできるので、PTY#getpty は deprecated として、
2.0（か 1.9.5 ？）で削除してしまう、ことを提案します。

同じことができるというのは事実誤認です。

少なくとも PTY.open と spawn には制御端末を設定する機能がありません。

[田中 哲][たなか あきら][Tanaka Akira]

[metanest (Makoto Kishimoto)]

きしもとです

同じことができるというのは事実誤認です。

少なくとも PTY.open と spawn には制御端末を設定する機能がありません。

わかりました。deprecated 以降についての提案は一旦ひっこめます。

あと、るりまの記述を確認していったところ、確認しきれなかったので、
どなたかわかるかたに質問したいのですが、

子プロセスの状態を監視するために SIGCHLD シグナルを捕捉します。
この記述が正しいのはいつ頃まででしょうか？

子プロセスが終了したり停止した場合には、例外 PTY::ChildExited が発生します。
ブロック付きの場合、1.8 と 1.9.1 r33056 では発生しますが、1.9.2 r32926 では
発生しません。ブロックなしの場合、1.9.1 でも発生しません。

この間、すべての SIGCHLD が PTY モジュールのシグナルハンドラに捕捉されるので、
サブプロセスを生成する他のメソッド(Kernel.#system や IO.popenなど)を使うと、
予期しない例外が発生することがあります。
1.8 でも確認できませんでした。
protect_signal が obsolete となったのは r1666 という非常に古いリビジョン
のようなので、もしかしてだいぶ古いことでしょうか？

[naruse (Yui NARUSE)]

• Target version changed from 1.9.3 to 2.6

[naruse (Yui NARUSE)]

• Target version deleted (2.6)

[mame (Yusuke Endoh)]

• Status changed from Assigned to Closed

rubyci の FreeBSD のログを手動で少しだけ見てみましたが、再現は見当たりませんでした。

http://rubyci.s3.amazonaws.com/freebsd11zfs/ruby-trunk/summary.html

岸本さんのところでも再現環境がすぐに用意できなくなっていると聞いたので、
とりあえず close しときたいと思います。