Forum: Ruby-Gnome 2 Disconnecting signal_connects before destroys

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

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

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

Quoting grant schoep (matobinder@gmail.com):

> 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 <path to the core file>

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 - fluido@fluido.as             che bisogno ci 
sarebbe
  *               di parlare tanto di amore e di rettitudine? 
(Chuang-Tzu)

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.

Carlo,

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