Disconnecting signal_connects before destroys

Desktop Ruby-Gnome 2
1

So I have an applications I support that has been randomly crashing, but
is
also stuck at an old Ruby and Ruby/Gnome2 build. But my question should
bypass that with “how should I do this, regardless of versions” My
question is, basically, good form to destroy things you create, or rely
on
the garbage collector? Here’s the SegV problem I am having…

So in my case, I am doing the following(yes, I know Canvas is
depricated
but this could apply to any GUI thing you do a signal_connect on.

spanPoly = Gnome::CanvasPolygon.new()

spanPoly.signal_connect(‘event’) do |item, event|

end

Ruby “randomly” is Seg Faulting with the following, (it does produce a
very non helpful core file).

somefile.rb:558: warning: instance variable holder not initialized
somefile.rb:558: [BUG] Segmentation fault

The line 558 is the signal_connect line above. I add those objects to an
array, and updated a view. At times they are destroyed.

My guess at what is happening, is I have destroyed the object. But
something is causing that signal_connect handler to run, but crashes
Ruby,
as its been destroyed. The “instance variable holder not initialized” is
a
clue to me I think.

In my code, should I really try to do a “signal_handler_disconnect” for
that action before I destroy it? Like

Create it like this:

spanPoly = Gnome::CanvasPolygon.new()

spanPolyEventId = spanPoly.signal_connect(‘event’) do |item, event|

end

Destroy it like this:

spanPoly.signal_handler_disconnect(spanPolyEventId)

spanPoly.destroy()

Is this maybe just good form? Trying to explicitly delete what you have
“newed”.

Thanks

2

Hi Grant:

In all the code I’ve written, I’ve never had to try to disconnect a
signal. I don’t know what’s causing the seg fault error, but I know
that I got a mysterious seg fault error when I was building a listview
and didn’t provide a :text column. It made something in GTK go haywire,
and everything behaved really strangely. It was very hard to locate the
problem.

So, I wouldn’t be surprised if the error is being caused elsewhere in
your code. What other widgets are you using between the constructor and
the destroy methods?

You could try making the shortest possible example by eliminating all
the code in between the constructor and destroy(), then start adding
until you get the error.

Hope it helps,
Eric

3

Subject: [ruby-gnome2-devel-en] Disconnecting signal_connects before
destroys
Date: gio 05 apr 12 05:05:11 -0600

Quoting grant schoep ([email protected]):

Ruby “randomly” is Seg Faulting with the following, (it does produce a
very non helpful core file).

The core file is very useful! Install gdb, and do:

gdb ruby

then do

bt

and you will see the complete tree of function calls that led to the
segfault. If you have compiled ruby-gnome yourself, and you have left
symbols in your libraries, you will find indication to the program
line in the C code that actually generated the segfault.

If you do not see source file names and line numbers, you can always
do

export CFLAGS="-O1 -g"

then go to the ruby-gnome source tree and do

make clean
ruby extconf.rb
make
sudo make install

and next time you segfault, GDB will show you source file and line
number. You will also be able to inspect variable values at the moment
the segfault has taken place.

Carlo

–

  •     Se la Strada e la sua Virtu' non fossero state messe da

parte,

  • K * Carlo E. Prelz - [email protected] che bisogno ci
    sarebbe 
    •           di parlare tanto di amore e di rettitudine?

(Chuang-Tzu)

4

I don’t know your code specifically and can not remember having used
this Canvas variant.

BUT, your error message sounds familiar.

I remember I once had that when I compiled against some older GTK
version.

somefile.rb:558: warning: instance variable holder not initialized
somefile.rb:558: [BUG] Segmentation fault

Often enough, I had something like this there:

foo.rb: (eval) warning

I always thought that something in ruby-gtk is using a very large
eval-style in order to call to C, or something like that.

5

Carlo,

That should be put on the wiki because it seems very useful. :slight_smile: