ymsdです。またまた、質問させてください。
前に、
>自作の拡張ライブラリがGCで落ちるのでデバッガでおいかけてみると、
>gc.cのなかのmark_locations_array(x, n)のnが65000とかになってる
>んですけど、これってすでに異常ですか？
という質問をしたら、オブジェクトが壊れているせいではないか、という
返事をいただきました。（ありがとうございました）
この原因がわかりました。（自分の調査不足でした。すみません）
私は、BeOSでrubyを使っていて、BeOSのGUIを扱う拡張ライブラリができない
かなあと、あれこれ試している者なのですが、BeOSはマルチスレッドが売り？
のOSなので、Windowを表示すると、rubyを走らせているスレッド(スレッドAと
よぶ）とは別のスレッド（スレッドBとよぶ）でWindowが走ります。GCはいつ
発生するかわからないので、スレッドBでGCが処理されることもあります。こ
のとき、BeOSではスレッドごとにスタックを積むので、rb_gc_stack_startはス
レッドAのスタックにあり、STACK_ENDはスレッドBのスタックにあります。
スレッドAのスタックとスレッドBのスタックは連続してとられるわけではない
ので、このままだと、mark_locations_arrayに渡る範囲には、スタックではない
領域も含まれてしまいます。その非スタック領域を触っているうちに落ちてし
まっていたのでした。
それで、gc.cにすこし手をいれて、それぞれのスレッドのスタック領域だけを
調査するようにしたら、GCでは落ちなくなりました。
しかし、まだまだ別の原因があるのだと思いますが、落ちまくるのです。
そこで、質問です。

  上のような、マルチスレッドな状況になった場合、rubyの動作に影響を及ぼ
すと思われるところが他にもあるでしょうか。

  XwindowとかWindows9x/NTでは似たような問題は発生しないのでしょうか

 それとも私はまだ勘違いしているのでしょうか

いつも質問ばかりですみませんが、よろしくおねがいいたします。
--
Masuda Yuichi
ymsd / m-net.ne.jp