Re: Segfault in Glib/Gtk2 script

[Discipulus]

Ouch! I'm really curious to know what your program does..

my 2 neurocents (I'd send you a msg iinstead of a probably unuseful post,if you were a named user..): I read: In my opinion crash happens because of direct call of perl exit() in GTK signal handlers. from an ubuntu forum.

They tell about a bug not always reproducible depending on library versions: in linux have you already tried to upgrade underlying libraries?

L*

[Anonymous Monk]

Ouch! I'm really curious to know what your program does..

It's a telnet/MUD client. I'll be uploading the source code to CPAN as soon as this segfault is resolved.

in linux have you already tried to upgrade underlying libraries?

Yes, the problem on the Ubuntu forum you referenced does sound a lot like my issue. And replacing the 'exit' statement and using 'Gtk2->main_quit()' instead does indeed remove the segfault.

(I had tried using both ->main_quit and exit together, unsuccesfully; it hadn't occured to me to remove 'exit' and keep ->main_quit).

[zentara]

Hi, I'm a little rusty on the old Gtk stuff, but I just want to mention something that may help you further.

You have to be careful with the return value of a delete_event, or any Gtk sub for that matter. Adding a 1 or 0 at the end of the sub can be needed sometimes.

#These are different in a very subtle manner.
$window->signal_connect( 'destroy', sub { Gtk2->main_quit() } );
$window->signal_connect(delete_event => sub { Gtk2->main_quit(); 1;});

See Gtk delete_event for more details.

From a previous problem like yours on the gtk maillist:



Returns: TRUE to stop other handlers from being invoked for the
event. FALSE to propagate the event further."

.... a return of TRUE from the delete-event
handler means "i handled this event, stop propagation."