Bug #3398: 1.9.2 SEGV during test-all

• Status: Closed
• Assignee: authorNari (Narihiro Nakamura)
• Target version: 2.0.0
• ruby -v: ruby 1.9.2dev (2010-06-06 revision 28184) [i386-darwin9.8.0]

[yugui (Yuki Sonoda)]

=begin
OSXで、TestArray#test_product中にSEGVが発生します。

rb_ary_productのt0が存在するheap slotがGCでfreeされてしまうのが原因のようです。t0に対するobj_freeは呼ばれないのでマーク漏れではないと思われ、もしかしたらheap slotのlimitがずれているのかも知れません。

ある程度大きなプログラムでないと再現しないようで、最小ケースは作成していませんが、私の環境では
make test-all TESTS='-v ruby/test_array.rb' RUNRUBYOPT='--debug'
により90%ぐらいの確率で再現します。

現在対応中です。
=end

[tarui (Masaya Tarui)]

=begin
樽家です。

2010年6月6日18:54 Yuki Sonoda [e-mail]:

Bug #3398: 1.9.2 SEGV during test-all
http://redmine.ruby-lang.org/issues/show/3398

起票者: Yuki Sonoda
ステータス: Assigned, 優先度: High
担当者: Yuki Sonoda, カテゴリ: core, Target version: 1.9.2
ruby -v: ruby 1.9.2dev (2010-06-06 revision 28184) [i386-darwin9.8.0]

OSXで、TestArray#test_product中にSEGVが発生します。

rb_ary_productのt0が存在するheap slotがGCでfreeされてしまうのが原因のようです。t0に対するobj_freeは呼ばれないのでマーク漏れではないと思われ、もしかしたらheap slotのlimitがずれているのかも知れません。

ある程度大きなプログラムでないと再現しないようで、最小ケースは作成していませんが、私の環境では
make test-all TESTS='-v ruby/test_array.rb' RUNRUBYOPT='--debug'
により90%ぐらいの確率で再現します。

現在対応中です。

---

http://redmine.ruby-lang.org

r28191 で 1.9.2については解決をしましたが、trunkでないからかredmineの開発者に登録されてないからか、連携でcloseできてません。
#手動でcloseも当然出来ない：-)

またtrunkについてはコードが大分変わっているために、そもそも同じ問題が起こるかどうかから確認がとれていませんが分かる人いませんか？

--
樽家昌也(Masaya TARUI)
No Tool,No Life.

=end

[okkez (okkez _)]

=begin
okkez です。

2010年6月7日0:26 Masaya TARUI [e-mail]:

樽家です。

r28191 で 1.9.2については解決をしましたが、trunkでないからかredmineの開発者に登録されてないからか、連携でcloseできてません。
#手動でcloseも当然出来ない：-)

Ruby と Ruby1.9 プロジェクトの Developper として追加しておきました。

--
okkez
[e-mail]

=end

[naruse (Yui NARUSE)]

• Status changed from Assigned to Closed

=begin

=end

[mame (Yusuke Endoh)]

• Status changed from Closed to Assigned
• Assignee changed from yugui (Yuki Sonoda) to authorNari (Narihiro Nakamura)
• Target version changed from 1.9.2 to 2.0.0

=begin
遠藤です。

この問題は ruby_1_9_2 では r28191 で解決されましたが、どうやら
trunk で残っているようです。#1934 を valgrind の下で実行すると
freelist の参照が free 済みの領域を指してしまっていることが
わかります。
lazy sweep の影響でコードが変わっているあたりということなので、
nari さんに見ていただければと思います。

...

of primes: 129 results: [] prime: 739 process time: 189.97

of primes: 130 results: [] prime: 743 process time: 197.16

of primes: 131 results: [] prime: 751 process time: 205.02

==24732==
==24732== Invalid read of size 4
==24732== at 0x8068492: rb_newobj (gc.c:1049)
==24732== by 0x817CDFB: ary_new (array.c:297)
==24732== by 0x817EA16: rb_ary_combination (array.c:331)
==24732== by 0x815AC61: vm_call0 (vm_eval.c:78)
==24732== by 0x815B98F: iterate_method (vm_eval.c:234)
==24732== by 0x81557C7: rb_iterate (vm_eval.c:851)
==24732== by 0x815595E: rb_block_call (vm_eval.c:931)
==24732== by 0x81A95FA: enumerator_each (enumerator.c:317)
==24732== by 0x815AC61: vm_call0 (vm_eval.c:78)
==24732== by 0x815B98F: iterate_method (vm_eval.c:234)
==24732== by 0x81557C7: rb_iterate (vm_eval.c:851)
==24732== by 0x815595E: rb_block_call (vm_eval.c:931)
==24732== Address 0x501c4d4 is 116 bytes inside a block of size 16,384 free'd
==24732== at 0x4022B8A: free (vg_replace_malloc.c:323)
==24732== by 0x806375C: free_unused_heaps (gc.c:1869)
==24732== by 0x816E2C4: rb_threadptr_execute_interrupts_rec (thread.c:1295)
==24732== by 0x816E58E: rb_thread_check_ints (thread.c:968)
==24732== by 0x81A616E: collect_all (enum.c:379)
==24732== by 0x8159C67: vm_yield_with_cfunc (vm_insnhelper.c:724)
==24732== by 0x8165CDE: rb_yield (vm.c:587)
==24732== by 0x817EA75: rb_ary_combination (array.c:4078)
==24732== by 0x815AC61: vm_call0 (vm_eval.c:78)
==24732== by 0x815B98F: iterate_method (vm_eval.c:234)
==24732== by 0x81557C7: rb_iterate (vm_eval.c:851)
==24732== by 0x815595E: rb_block_call (vm_eval.c:931)

--
Yusuke Endoh [e-mail]
=end

• Status changed from Assigned to Closed
• % Done changed from 0 to 100

=begin
This issue was solved with changeset r28472.
Yuki, thank you for reporting this issue.
Your contribution to Ruby is greatly appreciated.
May Ruby be with you.

=end