[#44014] Re: [ruby-core:37707] [Ruby 1.9 - Bug #3781] FIBER_USE_NATIVE が有効だと落ちるスクリプトがある — Narihiro Nakamura <authornari@...>

nariです。

14 messages 2011/07/02
[#44019] Re: [ruby-core:37707] [Ruby 1.9 - Bug #3781] FIBER_USE_NATIVE が有効だと落ちるスクリプトがある — KOSAKI Motohiro <kosaki.motohiro@...> 2011/07/02

> 本当はgc_mark()の際に毎回stack_check()するのがいいと思うのですが、

[#44027] [RubyKaigi] Next version of Ruby 1.8 and 1.9 — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

16 messages 2011/07/03

[#44156] [Ruby 1.9 - Feature #5053][Open] ruby コマンドと libruby の食い違いチェック — Makoto Kishimoto <redmine@...>

20 messages 2011/07/19

[#44185] [Ruby 1.9 - Bug #5074][Open] "[BUG] cfp consistency error - send" on TestEnumerator#test_feed_yielder (test/ruby/test_enumerator.rb) — Shota Fukumori <sorah@...>

10 messages 2011/07/22

[#44189] [Ruby 1.9 - Bug #5075][Assigned] invalid *fdp in Mac OS X and FreeBSD over recvmsg with SCM_RIGHTS — Yui NARUSE <naruse@...>

12 messages 2011/07/22

[#44210] 1.9.3 (以降) の BigDecimal について — Tadayoshi Funaba <tadf@...>

BigDecimal() で整数、浮動小数点数、有理数などを受けとれるようになって、

14 messages 2011/07/23
[#44275] Re: 1.9.3 (以降) の BigDecimal について — Tadayoshi Funaba <tadf@...> 2011/07/30

変換には明示的なものとそうでないものがありますが、

[#44276] Re: 1.9.3 (以降) の BigDecimal について — Kenta Murata <muraken@...> 2011/07/31

=E3=82=80=E3=82=89=E3=81=9F=E3=81=A7=E3=81=99=E3=80=82 =20

[#44223] [Ruby 1.9 - Bug #5094][Assigned] Supported platforms of Ruby 1.9.3 — Yui NARUSE <naruse@...>

21 messages 2011/07/25
[#44229] Re: [Ruby 1.9 - Bug #5094][Assigned] Supported platforms of Ruby 1.9.3 — KOSAKI Motohiro <kosaki.motohiro@...> 2011/07/25

> == 成瀬の提案

[#44230] Re: [Ruby 1.9 - Bug #5094][Assigned] Supported platforms of Ruby 1.9.3 — Urabe Shyouhei <shyouhei@...> 2011/07/26

卜部です

[#44236] Re: [Ruby 1.9 - Bug #5094][Assigned] Supported platforms of Ruby 1.9.3 — Yusuke ENDOH <mame@...> 2011/07/26

遠藤です。

[#44254] [Ruby 1.8 - Bug #5105][Open] CGI::Session#session_id の生成方法について — Masahiro Tomita <tommy@...>

14 messages 2011/07/27
[#44256] [Ruby 1.8 - Bug #5105] CGI::Session#session_id の生成方法について — Yui NARUSE <naruse@...> 2011/07/27

[#44258] Re: [Ruby 1.8 - Bug #5105] CGI::Session#session_id の生成方法について — とみたまさひろ <tommy@...> 2011/07/27

とみたです。

[#44262] Re: [Ruby 1.8 - Bug #5105] CGI::Session#session_id の生成方法について — "NARUSE, Yui" <naruse@...> 2011/07/27

(2011/07/27 19:47), とみたまさひろ wrote:

[#44263] Re: [Ruby 1.8 - Bug #5105] CGI::Session#session_id の生成方法について — とみたまさひろ <tommy@...> 2011/07/27

とみたです。

[#44270] Re: [Ruby 1.8 - Bug #5105] CGI::Session#session_id の生成方法について — とみたまさひろ <tommy@...> 2011/07/29

とみたです。

[#44271] Re: [Ruby 1.8 - Bug #5105] CGI::Session#session_id の生成方法について — Tanaka Akira <akr@...> 2011/07/29

2011年7月29日20:04 とみたまさひろ <tommy@tmtm.org>:

[ruby-dev:44014] Re: [ruby-core:37707] [Ruby 1.9 - Bug #3781] FIBER_USE_NATIVE が有効だと落ちるスクリプトがある

From: Narihiro Nakamura <authornari@...>
Date: 2011-07-02 05:04:00 UTC
List: ruby-dev #44014
nariです。

redmineだとruby-coreにメールされてしまうので、ruby-devにふります。
スタックオーバフローの原因は以下の2点です。

(1)マーク時に深い関数呼び出ししてしまうデータ構造が作り出される。
(2)gc.cのstack_check()がうまく働かない。

(1)についてはバックトレースを見るとよくわかるのですが、

  #1  0x00041e46c in gc_mark_children (objspace=.., ptr=12478400,
lev=19) at gc.c:1797
  #2  0x00041e199 in gc_mark (objspace=.., ptr=12478400, lev=18) at gc.c:1630
  #3  0x00041e73f in gc_mark_children (objspace=.., ptr=12483880,
lev=18) at gc.c:1850
  #4  0x00041e199 in gc_mark (objspace=.., ptr=12483880, lev=17) at gc.c:1630
  #5  0x00041e73f in gc_mark_children (objspace=.., ptr=12374280,
lev=17) at gc.c:1850
  #6  0x00041e199 in gc_mark (objspace=.., ptr=12374280, lev=16) at gc.c:1630
  ....
  #49 0x00041e73f in gc_mark_children (objspace=.., ptr=12320800,
lev=1) at gc.c:1850
  #50 0x00041e199 in gc_mark (objspace=.., ptr=12320800, lev=0) at gc.c:1630
  #51 0x00041da86 in mark_locations_array (objspace=.., x=0xe24278,
n=5) at gc.c:1401
  #52 0x00041daf3 in gc_mark_locations (objspace=.., start=0xe24270,
end=0xe242a8) at gc.c:1414
  #53 0x00041db29 in rb_gc_mark_locations (start=0xe24270,
end=0xe242a8) at gc.c:1420
  #54 0x000525fc5 in env_mark (ptr=0xe24220) at vm.c:238
  #55 0x00041e6aa in gc_mark_children (objspace=.., ptr=12320440,
lev=1) at gc.c:1838
  #56 0x00041e199 in gc_mark (objspace=.., ptr=12320440, lev=0) at gc.c:1630
  #57 0x00041e1da in rb_gc_mark (ptr=12320440) at gc.c:1636
  #58 0x0004182d1 in proc_mark (ptr=0xe242b0) at proc.c:53
  ....
  #66 0x000525fc5 in env_mark (ptr=0xe24340) at vm.c:238
  ...
  #70 0x0004182d1 in proc_mark (ptr=0xe243d0) at proc.c:53
  ...
  #78 0x000525fc5 in env_mark (ptr=0xe238e0) at vm.c:238
  ...
  #82 0x0004182d1 in proc_mark (ptr=0xe23970) at proc.c:53
  ...
  #90 0x000525fc5 in env_mark (ptr=0xde1580) at vm.c:238
  ...
  #94 0x0004182d1 in proc_mark (ptr=0xde1610) at proc.c:53
  ...
  #514 0x00041863e in binding_mark (ptr=0x95bb30) at proc.c:256

binding_markからはじまって、proc_mark,env_mark,proc_mark.... と続いてし
まうデータ構造がreduct.rbで作り出されています。
このようなデータ構造を作る最小の再現コードを書こうと思ったのですが意外
と難しく断念しました…。

上記のようなデータ構造を作ってしまうのはしょうがなさそうなので、(1)は問
題ではないと思っています。

続いて(2)です。

gc.cのstack_check()の役割としては
「lev(gc_mark()に渡される引数)がGC_LEVEL_MAX(250)の範囲でgc_mark()
を呼び出せるほどの余りがマシンスタックにあるかチェックする」
のように読めます。

  static int
  stack_check(void)
  {
  ...
      SET_STACK_END;
      ret = STACK_LENGTH > STACK_LEVEL_MAX - GC_WATER_MARK;

ただ、GC_WATER_MARKが512しかないので、そのチェックがうまくいってません。
GC_WATER_MARK = (gc_mark()フレームサイズ + gc_mark_children()フレームサイズ) * GC_LEVEL_MAX
となるべきだと思います。

私の環境(Linux 2.6.39-0-generic x86_64, gcc 4.5.2)ではgc_mark()と
gc_mark_children()のフレームが28ワードだったので、とりあえず以下のよう
に修正したいのですが、どうでしょうか?

この場合、GC_WATER_MARKは7000(64bit環境だと56KB)になります。
本当はgc_mark()の際に毎回stack_check()するのがいいと思うのですが、
そうするとGCの性能が落ちてしまうので、大体で決めてしまうしかないのか
なと思ってます。


diff --git a/gc.c b/gc.c
index d5b8dfd..df3fef9 100644
--- a/gc.c
+++ b/gc.c
@@ -1277,7 +1277,8 @@ ruby_get_stack_grow_direction(volatile VALUE *addr)
 }
 #endif

-#define GC_WATER_MARK 512
+#define GC_LEVEL_MAX 250
+#define GC_WATER_MARK (GC_LEVEL_MAX * 28)

 size_t
 ruby_stack_length(VALUE **p)
@@ -1600,8 +1601,6 @@ rb_gc_mark_maybe(VALUE obj)
     }
 }

-#define GC_LEVEL_MAX 250
-
 static void
 gc_mark(rb_objspace_t *objspace, VALUE ptr, int lev)
 {

In This Thread

Prev Next