<20001022071639P.moro / remus.dti.ne.jp>の記事において
JST時間2000年10月22日(日)07時16分39秒頃、moro / remus.dti.ne.jpさんは
書きました。

>>師星です。

	桑形です。

>>Gtk:CTreeですが、
>>snapshotではrow_dataを使っていなかったはず……と思ったらいつのまにか拙作
>>のパッチを取り込んでいただいていたのですね。
>>申し訳ありませんが、あれにはまだバグがありました。
>>segmentation faultは覚えがないのですが、たまにGCに異様に時間がかかること
>>と、nodelistを放置していたためにCTreeNodeがGCされないことは観測していま
>>した(nodelistはsnapshotではbind_ctree_nodeがコメントアウトされていて問題
>>でなくなっていますが)。
>>
>>すでに手元では修正し、一週間程度使っていて問題は出ていないのですが、
>>こちらには出していませんでした。
>>というわけでsnapshotのrbgtkctree.cに対するパッチです。

	添付されていたパッチを当てて再度スナップショットで
	試して見ましたがまだ落ちるようです。
	gdbで動作を追いかけてみました。Gtk::CListのGCでのmark
	で落ちているようです。
	シーケンスを追っかけてみたら

		(1). Gtk::CListを含むGtk::Windowを生成
		(2). (1)で作ったWindowをdestroy
			=> この時GtkClistで使用している領域を開放
		(3). Gtk::FileSelectionを生成
			=> この時(2)で開放された領域をGtkFileSelectionに
			   GTK+が割り当てる模様
		(4). その後の動作でGC::start
		(5). (1)で作ったオブジェクトをmarkしようとclist_marker_mark()
		   を呼び出し
			=> ここでGtkClist*からrow_listを評価する時に
			   Segmentation fault。

	(1)で生成されたオブジェクトの領域がまだRubyのGCチェック対象
	になっている様子ですが(未確認)、GTK+の世界では(3)で
	GtkFileSelectionに割り当て済なので論理矛盾が起こる…という
	感じのようです。

	どうもGtkCListのdestroy時にRuby側でもGCのチェック対象から
	外すようなコードが必要なようです。

#Gtk::CTreeでも同様の問題は起こりそうです。

	パッチはまだ作ってません、というより作るための情報を調べて
	る最中ですので私がやると(すごく)時間がかかる思います(*^^*;
	ってことで誰かやりません? (*^^*;


                                                   ζ
----                                            ^^y-
         くわがた@自宅
       kgt / topaz.ocn.ne.jp        − 年年歳歳花相似 歳歳年年人不同 −