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)
 {