ruby-gnome2-devel-ja — Ruby-GNOME2 developer's Mailing list. in Japanese.

Re: [ruby-gnome2-devel-ja] GLib::KeyFile#dup causes SEGV

[Masahiro S. () <sa...@to...>]

From: Masao Mutoh <mu...@hi...>
Date: Wed, 4 Jul 2007 11:15:44 +0900

> むとうです。
> 
> On Wed, 04 Jul 2007 06:37:52 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > 酒井です。
> > 
> > GLib::KeyFile は GBoxed として実装されていますが、copy関数の実装が適切
> > でないため、例えば 1000.times{ GLib::KeyFile.new.dup }; GC.start が
> > SEGV します。
> > copy/free を適切に実装できないのなら、GBoxedとして実装すべきではないと
> > 思います。
> 
> あー、なんか迷ったようなコードが残っていますね（苦笑）。
> GBoxedにするといろいろと楽なんですよね。

GBoxedと同じようなインターフェースの何かがあれば良いのかなぁ……

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cnVieS0xLjYueCA=?= =?iso-2022-jp?b?GyRCTVEkTiUzITwlSSROOm89fBsoQj8=?=

[Masahiro S. () <sa...@to...>]

From: Masao Mutoh <mu...@hi...>
Date: Wed, 4 Jul 2007 11:11:45 +0900

> むとうです。
> 
> On Wed, 04 Jul 2007 02:45:33 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > 酒井です。
>  
> > USE_POLL_FUNCの話からは離れますが、
> > ついでに 1.6.x と 1.7.x 用のコードも消してしまいたいところです。
> > (例えばallocationフレームワーク以前のためのコードとか)
> > 
> > 1.6ももうサポートしていなかったですよね?
> 
> そうですね。削除しちゃいましょう。

削除しちゃいました。
ちょっとすっきり。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] GLib::KeyFile#dup causes SEGV

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 04 Jul 2007 06:37:52 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> GLib::KeyFile は GBoxed として実装されていますが、copy関数の実装が適切
> でないため、例えば 1000.times{ GLib::KeyFile.new.dup }; GC.start が
> SEGV します。
> copy/free を適切に実装できないのなら、GBoxedとして実装すべきではないと
> 思います。

あー、なんか迷ったようなコードが残っていますね（苦笑）。
GBoxedにするといろいろと楽なんですよね。
うーん、どうしようかな。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cnVieS0xLjYueCA=?= =?iso-2022-jp?b?GyRCTVEkTiUzITwlSSROOm89fBsoQj8=?=

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 04 Jul 2007 02:45:33 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
 
> USE_POLL_FUNCの話からは離れますが、
> ついでに 1.6.x と 1.7.x 用のコードも消してしまいたいところです。
> (例えばallocationフレームワーク以前のためのコードとか)
> 
> 1.6ももうサポートしていなかったですよね?

そうですね。削除しちゃいましょう。

[ruby-gnome2-devel-ja] GLib::KeyFile#dup causes SEGV

[Masahiro S. () <sa...@to...>]

酒井です。

GLib::KeyFile は GBoxed として実装されていますが、copy関数の実装が適切
でないため、例えば 1000.times{ GLib::KeyFile.new.dup }; GC.start が
SEGV します。

copy/free を適切に実装できないのなら、GBoxedとして実装すべきではないと
思います。

--
酒井 政裕 / Masahiro Sakai

[ruby-gnome2-devel-ja] =?iso-2022-jp?b?cnVieS0xLjYueCA=?= =?iso-2022-jp?b?GyRCTVEkTiUzITwlSSROOm89fBsoQj8=?=

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Subject: Re: [ruby-gnome2-devel-ja] #define USE_POLL_FUNC 1
Date: Sat, 16 Jun 2007 13:34:22 +0900

> むとうです。

> > > 影響があるとしたら ruby 1.5.4 より前のバージョンですが、
> > > そんな昔のバージョンでは現在のコードは元から動かないので、
> > > 問題はないはずです。
> > 
> > あぁ、なるほど。失礼しました。
> > 
> > であれば、もういっそUSE_POOL_FUNCごとごっそり消しちゃいませ
> > んか？
> 
> #if 1 〜#endifの部分ですよね。1.5.4以前はもはやサポートする必要は
> ないので削除しちゃって問題無しですね。

USE_POLL_FUNCの話からは離れますが、
ついでに 1.6.x と 1.7.x 用のコードも消してしまいたいところです。
(例えばallocationフレームワーク以前のためのコードとか)

1.6ももうサポートしていなかったですよね?

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 20 Jun 2007 02:07:32 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。
> 
> From: Masao Mutoh <mu...@hi...>
> Date: Wed, 20 Jun 2007 01:52:02 +0900
> 
> > むとうです。
> > 
> > On Wed, 20 Jun 2007 01:38:05 +0900 (JST)
> > Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> > 
> > > 酒井です。
> > 
> > > > うげげ。
> > > > 解放済みのGRClosure上のcallbackやextra_argsをrb_gc_mark()してますね。
> > > > オブジェクトの寿命と解放に関する考察に抜けがありました。
> > > > 修正は簡単だと思うけど、また明日……
> > > 
> > > 修正しました。
> > 
> > ありがとうございます。
> > 例のtest_signal_disconnection.rbで確認しました。
> > 
> > ＃にしても、メモリリークしてるという質問者の意図を読み取るところ
> > ＃から始めるのは骨が折れますね・・・。もっと簡単なサンプルないのかな。
> 
> 多分、「シグナルハンドラをdisconnectしても、オブジェクトがブロックを参
> 照したままで、ブロックから参照されているオブジェクトがGCされない」とい
> う話でしょう。

そうみたいですね。
以下のスクリプトだとその要件って満たせてますかね？
ひとまず、メモリリークはしてないみたいなんですけど・・・。
＃それとも何か抜けあります？ Gtk.idle_addあたりがポイント？
 
require 'gtk2'

def test
  a = Gtk::Button.new
  handler_id = a.signal_connect("clicked"){1 + 1}
#  a.signal_handler_disconnect(handler_id)
#  a.destroy
end

loop {
  test
  GC.start
}

これでtopを見続けてもメモリ増えないんですよね。
GC.startを削ると増え続けるんですが。

Re: [ruby-gnome2-devel-ja] [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Wed, 20 Jun 2007 01:52:02 +0900

> むとうです。
> 
> On Wed, 20 Jun 2007 01:38:05 +0900 (JST)
> Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> 
> > 酒井です。
> 
> > > うげげ。
> > > 解放済みのGRClosure上のcallbackやextra_argsをrb_gc_mark()してますね。
> > > オブジェクトの寿命と解放に関する考察に抜けがありました。
> > > 修正は簡単だと思うけど、また明日……
> > 
> > 修正しました。
> 
> ありがとうございます。
> 例のtest_signal_disconnection.rbで確認しました。
> 
> ＃にしても、メモリリークしてるという質問者の意図を読み取るところ
> ＃から始めるのは骨が折れますね・・・。もっと簡単なサンプルないのかな。

多分、「シグナルハンドラをdisconnectしても、オブジェクトがブロックを参
照したままで、ブロックから参照されているオブジェクトがGCされない」とい
う話でしょう。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 20 Jun 2007 01:38:05 +0900 (JST)
Masahiro Sakai (酒井政裕) <sa...@to...> wrote:

> 酒井です。

> > うげげ。
> > 解放済みのGRClosure上のcallbackやextra_argsをrb_gc_mark()してますね。
> > オブジェクトの寿命と解放に関する考察に抜けがありました。
> > 修正は簡単だと思うけど、また明日……
> 
> 修正しました。

ありがとうございます。
例のtest_signal_disconnection.rbで確認しました。

＃にしても、メモリリークしてるという質問者の意図を読み取るところ
＃から始めるのは骨が折れますね・・・。もっと簡単なサンプルないのかな。

Re: [ruby-gnome2-devel-ja] [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masahiro Sakai (酒井政裕) <sa...@to...>
Date: Tue, 19 Jun 2007 01:19:55 +0900 (JST)

> 酒井です。
> 
> From: Masao Mutoh <mu...@hi...>
> Date: Mon, 18 Jun 2007 01:19:26 +0900
> 
> > むとうです。
> > 
> > Bug #1724347の件で、CVSの最新版のglib2
> > を使って添付されたtest_signal_disconnection.rb
> > を実行して見たところ、以下のようなメッセージが出ました。
> > 
> >  [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object
> > 
> > 0.16.0のglib2で置き換えると動作するので最近の修正が関係している
> > ようです。
> 
> うげげ。
> 解放済みのGRClosure上のcallbackやextra_argsをrb_gc_mark()してますね。
> オブジェクトの寿命と解放に関する考察に抜けがありました。
> 修正は簡単だと思うけど、また明日……

修正しました。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] #define USE_POLL_FUNC 1

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Sat, 16 Jun 2007 13:34:22 +0900

> むとうです。
> 
> On Sat, 16 Jun 2007 12:57:45 +0900 (JST)
> Kouhei Sutou <ko...@co...> wrote:
> 
> > 須藤です。
> > 
> > > > どんな影響があるのかよくわかっていないのですが、1.9対応のコー
> > > > ドにしては変だなぁと思っただけなのですが。。。
> > > 
> > > 現在の 1.9 では version.h がインストールされなくなっているようで、
> > > バージョンを比較できないため、こうしました。
> 
> そういえばRubyKaigi2007でどなたかが言ってました。
> version.hで見るのではなく、have_funcなどを使うように、
> とのことですが、

がーん。

> 今回みたいなケースではやっぱりversion.h
> なんかで判断したいですねー。
> 
> > > 影響があるとしたら ruby 1.5.4 より前のバージョンですが、
> > > そんな昔のバージョンでは現在のコードは元から動かないので、
> > > 問題はないはずです。
> > 
> > あぁ、なるほど。失礼しました。
> > 
> > であれば、もういっそUSE_POOL_FUNCごとごっそり消しちゃいませ
> > んか？
> 
> #if 1 〜#endifの部分ですよね。1.5.4以前はもはやサポートする必要は
> ないので削除しちゃって問題無しですね。さかいさんにお願いしちゃって
> いいんでしょうか？

削除しました。

> ちなみに、G_OS_WIN32の時はundefしてるので、USE_POLL_FUNC
> 自体はそのまま残すんですよね？

そうです。

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

[Masahiro S. () <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Mon, 18 Jun 2007 01:19:26 +0900

> むとうです。
> 
> Bug #1724347の件で、CVSの最新版のglib2
> を使って添付されたtest_signal_disconnection.rb
> を実行して見たところ、以下のようなメッセージが出ました。
> 
>  [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object
> 
> 0.16.0のglib2で置き換えると動作するので最近の修正が関係している
> ようです。

うげげ。
解放済みのGRClosure上のcallbackやextra_argsをrb_gc_mark()してますね。
オブジェクトの寿命と解放に関する考察に抜けがありました。
修正は簡単だと思うけど、また明日……

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

[Masao M. <mu...@hi...>]

さかいさん

むとうです。

とりあえずrbgobj_closure.cの変更が原因みたいです。
ということで、ちょっと見てもらっていいですか？

On Mon, 18 Jun 2007 01:19:26 +0900
Masao Mutoh <mu...@hi...> wrote:

> むとうです。
> 
> Bug #1724347の件で、CVSの最新版のglib2
> を使って添付されたtest_signal_disconnection.rb
> を実行して見たところ、以下のようなメッセージが出ました。
> 
>  [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object
> 
> 0.16.0のglib2で置き換えると動作するので最近の修正が関係している
> ようです。
> 
> 明日以降で調べようと思いますが今日は報告まで。

[ruby-gnome2-devel-ja] [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

[Masao M. <mu...@hi...>]

むとうです。

Bug #1724347の件で、CVSの最新版のglib2
を使って添付されたtest_signal_disconnection.rb
を実行して見たところ、以下のようなメッセージが出ました。

 [BUG] rb_gc_mark(): unknown data type 0x20(0xa15650) non object

0.16.0のglib2で置き換えると動作するので最近の修正が関係している
ようです。

明日以降で調べようと思いますが今日は報告まで。

Re: [ruby-gnome2-devel-ja] #define USE_POLL_FUNC 1

[Masao M. <mu...@hi...>]

むとうです。

On Sat, 16 Jun 2007 12:57:45 +0900 (JST)
Kouhei Sutou <ko...@co...> wrote:

> 須藤です。
> 
> > > どんな影響があるのかよくわかっていないのですが、1.9対応のコー
> > > ドにしては変だなぁと思っただけなのですが。。。
> > 
> > 現在の 1.9 では version.h がインストールされなくなっているようで、
> > バージョンを比較できないため、こうしました。

そういえばRubyKaigi2007でどなたかが言ってました。
version.hで見るのではなく、have_funcなどを使うように、
とのことですが、今回みたいなケースではやっぱりversion.h
なんかで判断したいですねー。
 
> > 影響があるとしたら ruby 1.5.4 より前のバージョンですが、
> > そんな昔のバージョンでは現在のコードは元から動かないので、
> > 問題はないはずです。
> 
> あぁ、なるほど。失礼しました。
> 
> であれば、もういっそUSE_POOL_FUNCごとごっそり消しちゃいませ
> んか？

#if 1 〜#endifの部分ですよね。1.5.4以前はもはやサポートする必要は
ないので削除しちゃって問題無しですね。さかいさんにお願いしちゃって
いいんでしょうか？

ちなみに、G_OS_WIN32の時はundefしてるので、USE_POLL_FUNC
自体はそのまま残すんですよね？

それでは。

Re: [ruby-gnome2-devel-ja] #define USE_POLL_FUNC 1

[Kouhei S. <ko...@co...>]

須藤です。

> > どんな影響があるのかよくわかっていないのですが、1.9対応のコー
> > ドにしては変だなぁと思っただけなのですが。。。
> 
> 現在の 1.9 では version.h がインストールされなくなっているようで、
> バージョンを比較できないため、こうしました。
> 
> 影響があるとしたら ruby 1.5.4 より前のバージョンですが、
> そんな昔のバージョンでは現在のコードは元から動かないので、
> 問題はないはずです。

あぁ、なるほど。失礼しました。

であれば、もういっそUSE_POOL_FUNCごとごっそり消しちゃいませ
んか？

Re: [ruby-gnome2-devel-ja] #define USE_POLL_FUNC 1

[Masahiro S. <sa...@to...>]

酒井です。

From: Kouhei Sutou <ko...@co...>
Date: Sat, 16 Jun 2007 11:57:27 +0900 (JST)

> 須藤です。
> 
> さっきの酒井さんのコミットの
> 
> > Index: rbglib_mainloop.c
> > ===================================================================
> > RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbglib_mainloop.c,v
> > retrieving revision 1.6
> > retrieving revision 1.7
> > diff -u -d -r1.6 -r1.7
> > --- rbglib_mainloop.c	29 Jun 2006 18:31:32 -0000	1.6
> > +++ rbglib_mainloop.c	16 Jun 2007 02:46:28 -0000	1.7
> > @@ -30,12 +30,17 @@
> >  /*****************************************/
> >  static VALUE rbglib_main_threads;
> >  
> > +/* FIXME */
> > +#if 1
> > +#define USE_POLL_FUNC 1
> > +#else
> >  #include <version.h>
> >  #if RUBY_VERSION_CODE >= 154
> >  # define USE_POLL_FUNC 1
> >  #else
> >  # undef USE_POLL_FUNC /* rb_thread_select() may cause busy wait */
> >  #endif
> > +#endif
> >  
> >  /* We can't use rbglib_poll() on native Win32.
> >     Because GPollFD doesn't have file descriptor but HANDLE. */
> 
> なのですが、もしかしてコミットミスだったりします？

すみません、コメントを書いておくべきでした。
これは意図的にこういうコードにしました。

> どんな影響があるのかよくわかっていないのですが、1.9対応のコー
> ドにしては変だなぁと思っただけなのですが。。。

現在の 1.9 では version.h がインストールされなくなっているようで、
バージョンを比較できないため、こうしました。

影響があるとしたら ruby 1.5.4 より前のバージョンですが、
そんな昔のバージョンでは現在のコードは元から動かないので、
問題はないはずです。

--
酒井 政裕 / Masahiro Sakai

[ruby-gnome2-devel-ja] #define USE_POLL_FUNC 1

[Kouhei S. <ko...@co...>]

須藤です。

さっきの酒井さんのコミットの

> Index: rbglib_mainloop.c
> ===================================================================
> RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbglib_mainloop.c,v
> retrieving revision 1.6
> retrieving revision 1.7
> diff -u -d -r1.6 -r1.7
> --- rbglib_mainloop.c	29 Jun 2006 18:31:32 -0000	1.6
> +++ rbglib_mainloop.c	16 Jun 2007 02:46:28 -0000	1.7
> @@ -30,12 +30,17 @@
>  /*****************************************/
>  static VALUE rbglib_main_threads;
>  
> +/* FIXME */
> +#if 1
> +#define USE_POLL_FUNC 1
> +#else
>  #include <version.h>
>  #if RUBY_VERSION_CODE >= 154
>  # define USE_POLL_FUNC 1
>  #else
>  # undef USE_POLL_FUNC /* rb_thread_select() may cause busy wait */
>  #endif
> +#endif
>  
>  /* We can't use rbglib_poll() on native Win32.
>     Because GPollFD doesn't have file descriptor but HANDLE. */

なのですが、もしかしてコミットミスだったりします？

どんな影響があるのかよくわかっていないのですが、1.9対応のコー
ドにしては変だなぁと思っただけなのですが。。。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cmJnb2JqX2Nsb3N1cmUuYyA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEY8QUxkGyhC?=

[Masao M. <mu...@hi...>]

むとうです。

On Wed, 13 Jun 2007 23:33:55 +0900 (JST)
Masahiro Sakai <sa...@to...> wrote:

> 酒井です。

> > 先日はどうもありがとうございました。
> 
> こちらこそ先日はどうもありがとうございました。
> むとうさんの発表良かったですよ。

いやぁ、緊張しまくりでしたよ（苦笑）。
 
> というわけで、チェックインしました。
> ChangeLogに怪しい英語を書くのも久しぶりです(^^;

いやー、ほんと久し振りですね！

私も徐々に復活します！

ではでは。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cmJnb2JqX2Nsb3N1cmUuYyA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEY8QUxkGyhC?=

[Masahiro S. <sa...@to...>]

酒井です。

From: Masao Mutoh <mu...@hi...>
Date: Tue, 12 Jun 2007 15:51:32 +0900

> むとうです。
> 
> On Tue, 12 Jun 2007 00:59:53 +0900 (JST)
> Masahiro Sakai <sa...@to...> wrote:
> 
> > 酒井です。
> > 
> > 1年前のメールですが、去年のRubyKaigi以来忘れていたのを、
> > 先日のRubyKaigiで思い出したので……
> 
> 先日はどうもありがとうございました。

こちらこそ先日はどうもありがとうございました。
むとうさんの発表良かったですよ。

> それにしても、またよく覚えてらっしゃいました（笑）。

何か忘れてることがあったなと思って手元のソースを見たら、
このコードがあったので、詳しいことはこれを見て思い出したのでした。

From: Masao Mutoh <mu...@hi...>
Date: Wed, 13 Jun 2007 21:40:02 +0900

> むとうです。
> 
> On Tue, 12 Jun 2007 16:05:27 +0900
> "Kouhei Sutou" <ko...@co...> wrote:
> 
> > 須藤です。
> > 
> > 07/06/12 に Masao Mutoh<mu...@hi...> さんは書きました:
> > 
> > > > > この場合の正解は、callbackとextra_argsをGRClosureHolderのフィールドに
> > > > > 持つようにして、markすることだと思います。
> > > >
> > > > これは以下のような感じのコードにしてはどうか、ということです。
> > > > 効率面だけでなく、GRClosureHolderというデータ構造が不要になる分、
> > > > コードも若干シンプルになると思います。
> > >
> > > なるほど。確かにシンプルですね。良いと思います。
> > > 須藤さんはどう思われますか？
> > 
> > 近いうちにリリースする予定はないですよね？
> > であれば、一度コミットしてもらってしばらく手元で動かしてみる
> > というのはどうでしょう。
> > 手元で使っていて何か問題がでたらrevertすればよいだけですし。
> 
> そうですね。さかいさん、久しぶりにチェックインしていただいても
> いいでしょうか？

というわけで、チェックインしました。
ChangeLogに怪しい英語を書くのも久しぶりです(^^;

--
酒井 政裕 / Masahiro Sakai

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cmJnb2JqX2Nsb3N1cmUuYyA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEY8QUxkGyhC?=

[Masao M. <mu...@hi...>]

むとうです。

On Tue, 12 Jun 2007 16:05:27 +0900
"Kouhei Sutou" <ko...@co...> wrote:

> 須藤です。
> 
> 07/06/12 に Masao Mutoh<mu...@hi...> さんは書きました:
> 
> > > > この場合の正解は、callbackとextra_argsをGRClosureHolderのフィールドに
> > > > 持つようにして、markすることだと思います。
> > >
> > > これは以下のような感じのコードにしてはどうか、ということです。
> > > 効率面だけでなく、GRClosureHolderというデータ構造が不要になる分、
> > > コードも若干シンプルになると思います。
> >
> > なるほど。確かにシンプルですね。良いと思います。
> > 須藤さんはどう思われますか？
> 
> 近いうちにリリースする予定はないですよね？
> であれば、一度コミットしてもらってしばらく手元で動かしてみる
> というのはどうでしょう。
> 手元で使っていて何か問題がでたらrevertすればよいだけですし。

そうですね。さかいさん、久しぶりにチェックインしていただいても
いいでしょうか？

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cmJnb2JqX2Nsb3N1cmUuYyA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEY8QUxkGyhC?=

[Kouhei S. <ko...@co...>]

須藤です。

07/06/12 に Masao Mutoh<mu...@hi...> さんは書きました:

> > > この場合の正解は、callbackとextra_argsをGRClosureHolderのフィールドに
> > > 持つようにして、markすることだと思います。
> >
> > これは以下のような感じのコードにしてはどうか、ということです。
> > 効率面だけでなく、GRClosureHolderというデータ構造が不要になる分、
> > コードも若干シンプルになると思います。
>
> なるほど。確かにシンプルですね。良いと思います。
> 須藤さんはどう思われますか？

近いうちにリリースする予定はないですよね？
であれば、一度コミットしてもらってしばらく手元で動かしてみる
というのはどうでしょう。
手元で使っていて何か問題がでたらrevertすればよいだけですし。

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cmJnb2JqX2Nsb3N1cmUuYyA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEY8QUxkGyhC?=

[Masao M. <mu...@hi...>]

むとうです。

On Tue, 12 Jun 2007 00:59:53 +0900 (JST)
Masahiro Sakai <sa...@to...> wrote:

> 酒井です。
> 
> 1年前のメールですが、去年のRubyKaigi以来忘れていたのを、
> 先日のRubyKaigiで思い出したので……

先日はどうもありがとうございました。
それにしても、またよく覚えてらっしゃいました（笑）。
 
> > この場合の正解は、callbackとextra_argsをGRClosureHolderのフィールドに
> > 持つようにして、markすることだと思います。
> 
> これは以下のような感じのコードにしてはどうか、ということです。
> 効率面だけでなく、GRClosureHolderというデータ構造が不要になる分、
> コードも若干シンプルになると思います。

なるほど。確かにシンプルですね。良いと思います。
須藤さんはどう思われますか？

Re: [ruby-gnome2-devel-ja] =?iso-2022-jp?b?cmJnb2JqX2Nsb3N1cmUuYyA=?= =?iso-2022-jp?b?GyRCJEskRCQkJEY8QUxkGyhC?=

[Masahiro S. <sa...@to...>]

酒井です。

1年前のメールですが、去年のRubyKaigi以来忘れていたのを、
先日のRubyKaigiで思い出したので……

From: Masahiro Sakai (酒井政裕) <sa...@to...>
Date: Sat, 27 May 2006 13:34:54 +0900 (JST)

> 酒井です。
> 
> From: Kouhei Sutou <ko...@co...>
> Date: Sat, 27 May 2006 13:15:51 +0900 (JST)
> 
> > 須藤です．
> > 
> > 私はあまり効率にこだわらないタイプです．ごめんなさい．
> > 
> > In <200...@to...>
> >   "[ruby-gnome2-devel-ja] rbgobj_closure.c について質問" on Sat, 27 May 2006 13:01:00 +0900 (JST),
> >   Masahiro Sakai (酒井政裕) <sa...@to...> wrote:
> > 
> > > > #define CALLBACK_KEY       rb_str_new2("callback")
> > > > #define EXTRA_ARGS_KEY     rb_str_new2("extra_args")
> > > 
> > > としていますが、これだと CALLBACK_KEY や EXTRA_ARGS_KEY が使われるごとに
> > > rb_str_new2することになって効率が悪いのではないでしょうか?
> > 
> > 常にメモリ上にもっておくことが嫌だったのでこうしました．
> > こだわっていないのでグローバルに持つようにしてもらってかまい
> > ません．
> 
> この場合の正解は、callbackとextra_argsをGRClosureHolderのフィールドに
> 持つようにして、markすることだと思います。

これは以下のような感じのコードにしてはどうか、ということです。
効率面だけでなく、GRClosureHolderというデータ構造が不要になる分、
コードも若干シンプルになると思います。

--
酒井 政裕 / Masahiro Sakai

Index: src/rbgobj_closure.c
===================================================================
RCS file: /cvsroot/ruby-gnome2/ruby-gnome2/glib/src/rbgobj_closure.c,v
retrieving revision 1.40
diff -u -p -r1.40 rbgobj_closure.c
--- src/rbgobj_closure.c	16 Dec 2006 05:01:30 -0000	1.40
+++ src/rbgobj_closure.c	11 Jun 2007 15:31:16 -0000
@@ -25,27 +25,14 @@
 #endif
 
 static ID id_call;
-static ID id_holder;
 static gboolean rclosure_initialized = FALSE;
 
-#define CALLBACK_KEY       rb_str_new2("callback")
-#define EXTRA_ARGS_KEY     rb_str_new2("extra_args")
-
-#define HOLDER(closure)       \
-  (rb_ivar_get((closure)->rb_holder, id_holder))
-#define SETUP_HOLDER(closure) \
-  (rb_ivar_set((closure)->rb_holder, id_holder, rb_hash_new()))
-
 typedef struct _GRClosure GRClosure;
-
-typedef struct _GRClosureHolder
-{
-    GRClosure *closure;
-} GRClosureHolder;
-
 struct _GRClosure
 {
     GClosure closure;
+    VALUE callback;
+    VALUE extra_args;
     VALUE rb_holder;
     gint count;
     GList *objects;
@@ -112,8 +99,8 @@ rclosure_marshal_do(VALUE arg_)
 
     if (rclosure_alive_p(rclosure)) {
         VALUE callback, extra_args;
-        callback = rb_hash_aref(HOLDER(rclosure), CALLBACK_KEY);
-        extra_args = rb_hash_aref(HOLDER(rclosure), EXTRA_ARGS_KEY);
+        callback = rclosure->callback;
+        extra_args = rclosure->extra_args;
 
         if (!NIL_P(extra_args)) {
             args = rb_ary_concat(args, extra_args);
@@ -249,13 +236,7 @@ rclosure_unref(GRClosure *rclosure)
         }
         g_list_free(rclosure->objects);
         rclosure->objects = NULL;
-
-        if (!NIL_P(rclosure->rb_holder)) {
-            GRClosureHolder *holder;
-            Data_Get_Struct(rclosure->rb_holder, GRClosureHolder, holder);
-            holder->closure = NULL;
-            rclosure->rb_holder = Qnil;
-        }
+        rclosure->rb_holder = Qnil;
     }
 }
 
@@ -271,36 +252,35 @@ rclosure_invalidate(gpointer data, GClos
 }
 
 static void
-gr_closure_holder_free(GRClosureHolder *holder)
+gr_closure_holder_mark(GRClosure *rclosure)
 {
-    if (holder) {
-        if (holder->closure) {
-            holder->closure->rb_holder = Qnil;
-            rclosure_invalidate(NULL, (GClosure *)(holder->closure));
-        }
-        free(holder);
-    }
+    rb_gc_mark(rclosure->callback);
+    rb_gc_mark(rclosure->extra_args);
+}
+
+static void
+gr_closure_holder_free(GRClosure *rclosure)
+{
+    rclosure->rb_holder = Qnil;
+    rclosure_invalidate(NULL, (GClosure*)rclosure);
 }
 
 GClosure*
 g_rclosure_new(VALUE callback_proc, VALUE extra_args, GValToRValSignalFunc g2r_func)
 {
     GRClosure* closure;
-    GRClosureHolder *holder;
 
     closure = (GRClosure*)g_closure_new_simple(sizeof(GRClosure), NULL);
 
     closure->count      = 1;
     closure->g2r_func   = g2r_func;
-    closure->rb_holder  = Data_Make_Struct(rb_cData, GRClosureHolder, 0,
-                                           gr_closure_holder_free, holder);
     closure->objects    = NULL;
-
-    holder->closure = closure;
-    SETUP_HOLDER(closure);
-
-    rb_hash_aset(HOLDER(closure), CALLBACK_KEY, callback_proc);
-    rb_hash_aset(HOLDER(closure), EXTRA_ARGS_KEY, extra_args);
+    closure->callback   = callback_proc;
+    closure->extra_args = extra_args;
+    closure->rb_holder  = Data_Wrap_Struct(rb_cData,
+                                           gr_closure_holder_mark,
+                                           gr_closure_holder_free,
+                                           closure);
 
     g_closure_set_marshal((GClosure*)closure, &rclosure_marshal);
     g_closure_add_invalidate_notifier((GClosure*)closure, NULL,
@@ -350,7 +330,6 @@ static void
 Init_rclosure()
 {
     id_call = rb_intern("call");
-    id_holder = rb_intern("holder");
 
 #ifdef HAVE_NATIVETHREAD
     /* startup the ruby thread to pull callbacks from other threads */

Re: [ruby-gnome2-devel-ja] [ 1724347 ] Signals are not properly destroyed

[Kouhei S. <ko...@co...>]

須藤です。

> この件って何かわかります？
> 
> http://sourceforge.net/tracker/index.php?func=detail&aid=1724347&group_id=53614&atid=470969

彼が何をいわんとしているのか理解できていないのですが、彼のサ
ンプルの最後に

  p :finished

  leaked_objects = Array.new
  11.times{ |i|
    hash_objects=Hash.new{|h,k|h[k]=0}

    GC.start
    ObjectSpace.each_object{|obj| hash_objects[obj.class]+=1 }
     leaked_objects<<hash_objects if i==0 or i==10

  }
  leaked_objects.each_with_index{|h,i|
     puts "LEAKED OBJECTS #{i}"
     h2 = leaked_objects[i+1]
     h2 = Hash.new{|h,k|h[k]=0} if not h2

     h.each_pair{|k,v|
       puts "Leaked #{k}: #{h2[k]-v}" if (h2[k]-v)>0
     }
     h2.each_pair{|k,v|
        puts "Leakdes #{k}: #{v-h[k]}" if (h[k] == 0) && (v != 0)
     }
  }

をつけると

  LEAKED OBJECTS 0
  Leaked Data: 10
  Leaked Gtk::VBox: 10
  Leaked Array: 11
  Leaked Hash: 13
  Leaked Proc: 13
  Leaked String: 19
  LEAKED OBJECTS 1
  :finished
  LEAKED OBJECTS 0
  Leaked Array: 1
  Leaked Hash: 2
  Leaked Proc: 2
  LEAKED OBJECTS 1

となるので、リークしていないと思います。
こういうことじゃなかったらごめんなさい。