Re: Segmentation fault in gtk2-perl-application

Thank you, Ross and muppet, for your mails. You make me hope that this issue 
is resolvable and not a bad demons sword hanging over the stability of my 

Am Donnerstag 31 März 2005 04:33 schrieb muppet:
On Mar 30, 2005, at 4:59 PM, Stephan Brunner wrote:


I would be very glad if you could help me out with this issue by
giving advice on where and how to start investigating what's going
(wr)on(g) in my application. Of course, I am happy to provide you any
information needed;

What versions of gtk+, glib, Gtk2, and Glib are you using?  what

I run Debian Sarge on x86; that came with gtk+ 2.6.2, glib 2.6.3, Gtk2 and 
Glib 1.062. My personal debug-build of Gtk2 and Glib is 1.080.

Beyond that, seeing the code is really going to be necessary.

Here it is -- to my own surprise, I was able to delete pretty much everything 
of my script and still get the segfault. What's left is not more than a very 
basic gtk2-app that does nothing else than prompt for a directory if you 
select File->open directory or hit Ctrl-O:

***** snip

use warnings;
use strict;

# include my debug-build of Gtk2 and Glib
#use lib '/home/stephan/Work/imTuS/segv/lib/perl/5.8.4/';
use Gtk2 '-init';

use constant FALSE => 0;
use constant TRUE => 1;

### Hauptfenster 
my %Top;
$Top{window} = Gtk2::Window->new;
$Top{window}->set_title('Segmentation fault?');
$Top{window}->set_default_size(400, 400);
$Top{window}->signal_connect (destroy => sub { Gtk2->main_quit; });

### Grund-Layout
# VBox
$Top{vbox} = Gtk2::VBox->new(FALSE, 5);

### Menu
# Layout
my %Menu;
$Menu{string} = <<"EOS";
  <menubar name='Menu'>
    <menu action='File'>
    <menuitem action='loadDir'/>

# Actions erzeugen
$Menu{actions} = [
      [ 'File', undef, 'File' ], 
      [ "loadDir",  undef,    "Open directory", "<control>O", undef, 
\&loadDir ]
$Menu{action_group} = Gtk2::ActionGroup->new('Menu');

# UIManager erzeugen
$Menu{manager} = Gtk2::UIManager->new();

# Actions dem UIManager uebergeben
$Menu{manager}->insert_action_group($Menu{action_group}, 0);

# Mit UIManager Menü aus Menu{string} erzeugen

# Accelerators (automatisch erzeugt) abfragen und dem Toplevel-Window zuweisen
$Menu{accel_group} = $Menu{manager}->get_accel_group();

# Menu der Top-VBox zuweisen
$Top{vbox}->pack_start($Menu{manager}->get_widget('/Menu'), 0, 0, 0);


sub loadDir {
    print "Entering sub loadDir...\n";
    my $dlg = Gtk2::FileChooserDialog->new('Select directory', undef,
         'gtk-cancel' => 'cancel',
         'gtk-open' => 'ok');
    my $response = $dlg->run();
    if ($response ne 'ok') {
 print "You aborted.\n";
    else {
 print 'You selected: >' . $dlg->get_filename . "<\n";
    print "Leaving sub loadDir...\n";

***** snap

The probability of getting the segfault depends on the directory selected --  
there is a folder in my $HOME that almost always results in the segfault.

not knowing what information might help, I only attached the output of
gdb for a "bt" command.

the backtrace was very useful, in that it points out that error is
occurring deep inside gtk+, in a function that should not really have
any cause to generate a segfault.  this usually means there is memory
corruption somewhere.

For the above sample-script, I created a new backtrace which is much shorter 
than the one I sent yesterday:

(gdb) bt
#0  0x40769d9c in gtk_path_bar_get_type () from /usr/lib/
#1  0x402d6ddc in g_main_context_wakeup () from /usr/lib/
#2  0x402d46c2 in g_main_depth () from /usr/lib/
#3  0x402d5748 in g_main_context_dispatch () from /usr/lib/
#4  0x402d5a80 in g_main_context_dispatch () from /usr/lib/
#5  0x402d6023 in g_main_loop_run () from /usr/lib/
#6  0x407418f3 in gtk_main () from /usr/lib/
#7  0x40402942 in XS_Gtk2_main (my_perl=0x814c008, cv=0x821c680) at Gtk2.c:374
#8  0x080c32d6 in Perl_pp_entersub ()
#9  0x080bbdc9 in Perl_runops_standard ()
#10 0x080635e8 in perl_run ()
#11 0x080633f5 in perl_run ()
#12 0x0805fb9f in main ()

If you're on an x86 system, please try running your program with
valgrind.  Don't be surprised by "still reachable" leaks (glib has lots
of memory that it assumes lives for the life of the program and
therefore doesn't clean up) and some "jump on uninitialized value"
errors from within Xlib; watch for errors that occur when you trigger
your callback.  If you find something, generate and capture the output
with --num-callers=50 --- gtk+ applications' stacks tend to be very
deep, and the defaults only show 5 stack frames.

Running the sample script with valgrind, I saw some messages (errors?) that 
seem to occur right before the segfault. Hopefully you can extract some hints 
of the attached valgrind-output (gzipped)?!
The above script is so short and simple that I am stunned it can segfault. I 
must be doing something really weird within this few lines of code...!? As it 
is so short and simple, I have much hope that we (well, that is mostly 
you:-)) are able to trace the problem down to its root cause.

Thank you for your support!


Attachment: valgrind.log.gz
Description: GNU Zip compressed data

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