Re: segv on exit from certain uimanager program

On Nov 29, 2007, at 7:18 PM, Kevin Ryde wrote:

I get a segv from the program below when using the mouse to select
File/Quit.  This is on a recent debian i386 with gtk-perl 1.161, perl
5.8.8, gtk 2.12.1 and glib 2.14.3.

Reproduced on Fedora Core 2 with both stock gtk+ 2.4.14 and with a derelict gtk+ 2.11.6 from svn.

Sticking it under gdb shows it deep under gtk_ui_manager_finalize, with
"signal_emit_unlocked_R" apparently having got a bad "emission_list",
presumably on the destroy signal of some object within that uimanager.
But beyond that it's a mystery to me.

Sounds a lot like a reference cycle left you with a bad pointer during cleanup. See below.

I struck this in my own program using a uimanager.  There seems to be
number of ways to avoid the problem,

   * use the keyboad to choose File/Quit (instead of the mouse)
   * Gtk2->main_quit instead of "exit 0"
   * don't hold the uimanager in $toplevel->{'ui'}
   * don't have an empty toolbar section in the ui spec

I can also avoid the crash by adding

   my $toolbar = $ui->get_widget ('/ToolBar');
   $vbox->pack_start ($toolbar, 0, 0, 0);

regardless of whether it contains any tool items.

Alternatively, this seems to cure it, as well:

   $toplevel->signal_connect (destroy => sub { delete $_[0]{ui} });

That's a typical way to break a reference cycle, which may be the root of the problem.

A more idiomatic way to quit the program would be like this:

   $toplevel->signal_connect (destroy => sub { Gtk2->main_quit });
sub do_quit { $toplevel->destroy } # a confirmation prompt would go here

This has the added benefit of making your script finish properly when the user kills the window via the window manager.

The Master in the art of living makes little distinction between his work and his play, his labor and his leisure, his mind and his body, his education and his recreation, his love and his religion. He hardly knows which is which. He simply pursues his vision of excellence in whatever he does, leaving others to decide whether he is working or playing. To him he is always doing both.

  -- Zen Philosophy

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]