From: Narihiro Nakamura Date: 2011-07-02T14:04:00+09:00 Subject: [ruby-dev:44014] Re: [ruby-core:37707] [Ruby 1.9 - Bug #3781] FIBER_USE_NATIVE が有効だと落ちるスクリプトがある 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) {