Thu, May 04, 2006 at 01:22:22PM +0900, Masao Mutoh wrote:
Hi Sjoerd,
Sat, 29 Apr 2006 16:05:44 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:
Strangely, both fixed the problem for me (with current anon CVS and with the
vanilla 0.14.1 release) Can you send a backtrace the segv you get ?
As Joao said, Anon CVS hasn't been updated for a long time.
I reported it, but it still doesn't fix.
Still isn't fixed unfortunately :(
So, I attached the latest Ruby/GLib2 to this mail which applied your patch.
#rbgobj_closure.c.org is the latest file on CVS.
And the result of backtrace is /gdb_result1.txt.
Unfortunately, gdb result doesn't have any good informations.
I suspect I did something wrong when I applied your patch by hand.
I've looked at it, your patched version wouldn't work for me:
(ruby: symbol lookup error: /
undefined symbol: g_rclosure_attach)
So i redid the patch based on the rbgobj_closure.c.org file, which works nicely
again.
In the mean time i've updated the patch a little, the callback thread now
has abort_on_exception set by default and ensures that no callbacks from other
thread will deadlocked when an exceptions occurs. This is somewhat more
natural as the callback thread is somewhat hidden from the programmer.
Unfortunately it also means that you cannot catch a callback error outside of
the callback proc object itself (which sucks somewhats)
I've attached both the patch and the complete patched rbgobj_closure.c file.
Hope this works for you :)
Sjoerd

Hi Sjoerd,

Again, it didn't work .
I applied your patch to newest Ruby/GLib2 and test it.
It occured segfault.

My gstreamer is 0.8.12.
Should I test it later versions ?

# I applied gdb log and your avtest what I used.

Wed, 10 May 2006 01:03:24 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Thu, May 04, 2006 at 01:22:22PM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Sat, 29 Apr 2006 16:05:44 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Strangely, both fixed the problem for me (with current anon CVS and with the
vanilla 0.14.1 release) Can you send a backtrace the segv you get ?

As Joao said, Anon CVS hasn't been updated for a long time.
I reported it, but it still doesn't fix.

Still isn't fixed unfortunately :(

So, I attached the latest Ruby/GLib2 to this mail which applied your patch.
#rbgobj_closure.c.org is the latest file on CVS.

And the result of backtrace is /gdb_result1.txt.
Unfortunately, gdb result doesn't have any good informations.

I suspect I did something wrong when I applied your patch by hand.

I've looked at it, your patched version wouldn't work for me:
(ruby: symbol lookup error: /
undefined symbol: g_rclosure_attach)

So i redid the patch based on the rbgobj_closure.c.org file, which works nicely
again.

In the mean time i've updated the patch a little, the callback thread now
has abort_on_exception set by default and ensures that no callbacks from other
thread will deadlocked when an exceptions occurs. This is somewhat more
natural as the callback thread is somewhat hidden from the programmer.

Unfortunately it also means that you cannot catch a callback error outside of
the callback proc object itself (which sucks somewhats)

I've attached both the patch and the complete patched rbgobj_closure.c file.
Hope this works for you :)

Sjoerd

Sun, May 14, 2006 at 11:12:54PM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Again, it didn't work .
I applied your patch to newest Ruby/GLib2 and test it.
It occured segfault.

, after some valgrinding it seems that the gc was messing with the created
thread for some reason Fixed in this patch.

The patch is also somewhat simpler then the previous one, because it no longer
has to handle exceptions.

Hope this one works for you ;)

Sjoerd

Hi Sjoerd,

Unfortunately, it still doesn't work

gstreamer 0.8.12.
glib2 2.8.1
ruby 1.8.4 (2005-12-24) [i686-linux]

Fri, 19 May 2006 12:55:17 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Sun, May 14, 2006 at 11:12:54PM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Again, it didn't work .
I applied your patch to newest Ruby/GLib2 and test it.
It occured segfault.

, after some valgrinding it seems that the gc was messing with the created
thread for some reason Fixed in this patch.

The patch is also somewhat simpler then the previous one, because it no longer
has to handle exceptions.

Hope this one works for you ;)

Sjoerd

Sat, May 20, 2006 at 12:55:54PM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Unfortunately, it still doesn't work

Then i'm out of ideas. I've attached a version with various printf's for
debugging. If possible could you also provide a valgrind log and a gdb
``thread apply all bt full'' traceback ?

Sjoerd

Hi,

In <20060519105517.GA22233 (AT) spring (DOT) luon.net>
"Re: [ruby-gnome2-devel-en] [Patch] handle glib signals coming from different threads" on Fri, 19 May 2006 12:55:17 +0200,
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Again, it didn't work .
I applied your patch to newest Ruby/GLib2 and test it.
It occured segfault.

, after some valgrinding it seems that the gc was messing with the created
thread for some reason Fixed in this patch.

In my environment, it seems this patch fixes this problem.

Thanks,

Hi Sjoerd,

Sun, 21 May 2006 14:43:12 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Sat, May 20, 2006 at 12:55:54PM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Unfortunately, it still doesn't work

Then i'm out of ideas. I've attached a version with various printf's for
debugging. If possible could you also provide a valgrind log and a gdb
``thread apply all bt full'' traceback ?

K, here is a gdb log.

Hi,

Mon, 22 May 2006 23:10:13 +0900 (JST)
Kouhei Sutou <kou (AT) cozmixng (DOT) orgwrote:

Hi,

In <20060519105517.GA22233 (AT) spring (DOT) luon.net>
"Re: [ruby-gnome2-devel-en] [Patch] handle glib signals coming from different threads" on Fri, 19 May 2006 12:55:17 +0200,
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Again, it didn't work .
I applied your patch to newest Ruby/GLib2 and test it.
It occured segfault.

, after some valgrinding it seems that the gc was messing with the created
thread for some reason Fixed in this patch.

In my environment, it seems this patch fixes this problem.

Could you tell me more detail about your environment?

I'm afraid my environment something wrong.

Tue, May 23, 2006 at 01:59:12AM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Sun, 21 May 2006 14:43:12 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Sat, May 20, 2006 at 12:55:54PM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Unfortunately, it still doesn't work

Then i'm out of ideas. I've attached a version with various printf's for
debugging. If possible could you also provide a valgrind log and a gdb
``thread apply all bt full'' traceback ?

K, here is a gdb log.

Ah, i think i know what's going wrong The output shows you get a normal
callback, while the traceback indicates that it comes from another thread
This probably means that your ruby isn't configured with Can
you check that?

If isn't enabled then is_ruby_native_thread() will always
return true, causing the normal codepath to be used (which is basically the
same as what happens to an unpatched version)

Sjoerd

Hi,

In <20060523020010.58462e85.mutoh (AT) highway (DOT) ne.jp>
"Re: [ruby-gnome2-devel-en] [Patch] handle glib signals coming from different threads" on Tue, 23 May 2006 02:00:10 +0900,
Masao Mutoh <mutoh (AT) highway (DOT) ne.jpwrote:

, after some valgrinding it seems that the gc was messing with the created
thread for some reason Fixed in this patch.

In my environment, it seems this patch fixes this problem.

Could you tell me more detail about your environment?

I'm sorry, I should show detail about my environment. Here
is my environment:

% pkg-config gstreamer-0.8
0.8.12
% pkg-config glib-2.0
2.10.2
% ruby -v
ruby 1.8.4 (2005-12-24) [i486-linux]

I'm using Debian/GNU Linux unstable.

Thanks,

Hi,

Tue, 23 May 2006 00:20:31 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Tue, May 23, 2006 at 01:59:12AM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Sun, 21 May 2006 14:43:12 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Sat, May 20, 2006 at 12:55:54PM +0900, Masao Mutoh wrote:
Hi Sjoerd,

Unfortunately, it still doesn't work

Then i'm out of ideas. I've attached a version with various printf's for
debugging. If possible could you also provide a valgrind log and a gdb
``thread apply all bt full'' traceback ?

K, here is a gdb log.

Ah, i think i know what's going wrong The output shows you get a normal
callback, while the traceback indicates that it comes from another thread
This probably means that your ruby isn't configured with Can
you check that?

Sure. I don't use any options when I configured ruby.
I tried latest ruby in CVS (1.9.0) with , your patch works.

If isn't enabled then is_ruby_native_thread() will always
return true, causing the normal codepath to be used (which is basically the
same as what happens to an unpatched version)

AFAIK, is option(not standard) now, isn't it?

So, if your patch doesn't influence ruby with option,
I'll apply your patch to CVS.

What do you think?

Wed, May 24, 2006 at 12:42:09AM +0900, Masao Mutoh wrote:
Tue, 23 May 2006 00:20:31 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Tue, May 23, 2006 at 01:59:12AM +0900, Masao Mutoh wrote:
Ah, i think i know what's going wrong The output shows you get a normal
callback, while the traceback indicates that it comes from another thread
This probably means that your ruby isn't configured with
Can you check that?

Sure. I don't use any options when I configured ruby.
I tried latest ruby in CVS (1.9.0) with , your patch works.

If isn't enabled then is_ruby_native_thread() will always
return true, causing the normal codepath to be used (which is basically the
same as what happens to an unpatched version)

AFAIK, is option(not standard) now, isn't it?

So, if your patch doesn't influence ruby with option,
I'll apply your patch to CVS.

What do you think?

Sounds great. Very nice to have this mystery solved :) I've attached a version
of the patch that only enables the code when HAVE_NATIVETHREAD is defined (thus
when ruby is compiled with ).

I'll add a note to my ruby gst 0.10 bindings that people should really use a
ruby version compiled with You might want to do that for ruby
gstreamer 0.8 (as that should improve stability a lot).

For the record, Debian's ruby is compiled with by default
while Fedora's ruby uses

Sjoerd

Hi Sjoerd,

K. Applied it, too.

Tue, 23 May 2006 19:12:26 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Wed, May 24, 2006 at 12:42:09AM +0900, Masao Mutoh wrote:
Tue, 23 May 2006 00:20:31 +0200
sjoerd (AT) spring (DOT) luon.net (Sjoerd Simons) wrote:

Tue, May 23, 2006 at 01:59:12AM +0900, Masao Mutoh wrote:
Ah, i think i know what's going wrong The output shows you get a normal
callback, while the traceback indicates that it comes from another thread
This probably means that your ruby isn't configured with
Can you check that?

Sure. I don't use any options when I configured ruby.
I tried latest ruby in CVS (1.9.0) with , your patch works.

If isn't enabled then is_ruby_native_thread() will always
return true, causing the normal codepath to be used (which is basically the
same as what happens to an unpatched version)

AFAIK, is option(not standard) now, isn't it?

So, if your patch doesn't influence ruby with option,
I'll apply your patch to CVS.

What do you think?

Sounds great. Very nice to have this mystery solved :) I've attached a version
of the patch that only enables the code when HAVE_NATIVETHREAD is defined (thus
when ruby is compiled with ).

I'll add a note to my ruby gst 0.10 bindings that people should really use a
ruby version compiled with You might want to do that for ruby
gstreamer 0.8 (as that should improve stability a lot).

For the record, Debian's ruby is compiled with by default
while Fedora's ruby uses

Sjoerd