Bug #3398

1.9.2 SEGV during test-all

Added by Yuki Sonoda about 5 years ago. Updated over 4 years ago.

[ruby-dev:41543]
Status:Closed
Priority:Normal
Assignee:Narihiro Nakamura
ruby -v:ruby 1.9.2dev (2010-06-06 revision 28184) [i386-darwin9.8.0] Backport:

Description

=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

History

#1 Updated by Masaya Tarui about 5 years ago

=begin
樽家です。

2010年6月6日18:54 Yuki Sonoda redmine@ruby-lang.org:

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

#2 Updated by okkez _ about 5 years ago

=begin
okkez です。

2010年6月7日0:26 Masaya TARUI tarui@prx.jp:

樽家です。

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

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

--
okkez
okkez000@gmail.com

=end

#3 Updated by Yui NARUSE about 5 years ago

  • Status changed from Assigned to Closed

=begin

=end

#4 Updated by Yusuke Endoh about 5 years ago

  • Status changed from Closed to Assigned
  • Assignee changed from Yuki Sonoda to 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 mame@tsg.ne.jp
=end

#5 Updated by Anonymous about 5 years ago

  • 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

Also available in: Atom PDF