[ruby-dev:35279] Re: [BUG] test_win32ole_event.rb in trunk

こんにちは、なかむら(う)です。

引用順をいじります。

In message "[ruby-dev:35278] [BUG] test_win32ole_event.rb in trunk"
    on Jun.30,2008 23:54:26, <[e-mail]> wrote:
> タイミング的には、
> 
>     * gc.c (rb_newobj): prohibit call of rb_newobj() during gc when
>       USE_VALUE_CACHE is not defined (normal case).
> 
> の変更が入ってからなのですが、この変更が悪いとは考えにくいので、
> WIN32OLE_EVENTの実装の方に元々問題があったんじゃないかと疑っています。
> ただ、どこが悪いのか、今のところ見当がつきません。

もともと、このチェックは1.8系にあったもので、1.9.0-2が出るち
ょっと前に1.9にもマージされました。
が、実はこのマージがミスっていて、現状有効でない#ifブロックの
中にあったので、上記のcommitで本来の意図通りチェックが行われ
るようになりました。

ただ、実際にこのチェックを有効にしてみるとruby本体にも問題が
あることが判明したため、r17732およびr17737で対応が加えられま
した。

ここまでが今日...じゃないな、昨日のあらすじです。


で、このチェックが何をしているかというと、[BUG]メッセージの通
りで、本来禁止しなければならない、GC実行中のrubyオブジェクト
の確保を検出しています。
# GC実行中にrubyオブジェクトを確保してもうまく動いてしまうの
# は、たまたまheap slotに空きがある場合だけで、要するに運がい
# い場合だけです(と、私はこの話を理解しています)。


> GC.startがコールされたところで、このBUGが発生するのは
> 拡張ライブラリとして、どういう実装をした場合が考えられるでしょうか？

GC実行中というのは、要するにmark中またはsweep中またはファイナ
ライザ実行中です。
というわけで、mark関数またはfree関数内でメモリ確保を行ってい
る可能性が高いです。
... が、win32ole.cを見た限りだと単純にそんなことをしているケ
ースはないですね。


> あと、[BUG]の出力が延々繰り返される動きが気になってます。

私もこれは気になります。
なんでabort()で終了してないんだろ?


それでは。
-- 
U.Nakamura <[e-mail]>