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 application... 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 OS/dist?
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
#!/usr/bin/perl
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);
$Top{window}->add($Top{vbox});
### Menu
# Layout
my %Menu;
$Menu{string} = <<"EOS";
<ui>
<menubar name='Menu'>
<menu action='File'>
<menuitem action='loadDir'/>
</menu>
</menubar>
</ui>
EOS
# Actions erzeugen
$Menu{actions} = [
[ 'File', undef, 'File' ],
[ "loadDir", undef, "Open directory", "<control>O", undef,
\&loadDir ]
];
$Menu{action_group} = Gtk2::ActionGroup->new('Menu');
$Menu{action_group}->add_actions($Menu{actions});
# 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
$Menu{manager}->add_ui_from_string($Menu{string});
# Accelerators (automatisch erzeugt) abfragen und dem Toplevel-Window zuweisen
$Menu{accel_group} = $Menu{manager}->get_accel_group();
$Top{window}->add_accel_group($Menu{accel_group});
# Menu der Top-VBox zuweisen
$Top{vbox}->pack_start($Menu{manager}->get_widget('/Menu'), 0, 0, 0);
$Top{window}->show_all;
Gtk2->main;
###
sub loadDir {
print "Entering sub loadDir...\n";
my $dlg = Gtk2::FileChooserDialog->new('Select directory', undef,
'select-folder',
'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";
}
$dlg->destroy();
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/libgtk-x11-2.0.so.0 #1 0x402d6ddc in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0 #2 0x402d46c2 in g_main_depth () from /usr/lib/libglib-2.0.so.0 #3 0x402d5748 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x402d5a80 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #5 0x402d6023 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #6 0x407418f3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #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! Stephan
Attachment:
valgrind.log.gz
Description: GNU Zip compressed data