Re: Segmentation fault in gtk2-perl-application

Am Freitag 01 April 2005 02:55 schrieb muppet:
On Mar 31, 2005, at 4:20 PM, Stephan Brunner wrote:
Am Donnerstag 31 März 2005 04:33 schrieb muppet:
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
Glib 1.062. My personal debug-build of Gtk2 and Glib is 1.080.

on Fedora 2 with glib-2.4.0, gtk+ 2.4.7, Glib/Gtk2 1.080, i can't seem
to reproduce the failure with your script.

same results in my cvs sandbox, which has glib-2.6.5 and gtk+ 2.6.4.

I was afraid you couldn't reproduce the error, as that doesn't make things 
easier. Anyway, I will continue to provide backtraces and valgrind-reports 
and anything else that might help...

Even though I really don't think it depends that strong on the actual 
directory names or structures, you could try the directory names I described 

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
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
select File->open directory or hit Ctrl-O:

what about this even shorter version?  does it still exhibit the same
behavior?  (i merely replaced the UIManager gui with a simple window
containing a button.  if this one still crashes, we can rule out
UIManager interactions...)


Yes, this script also segfaults. The backtrace is pretty much the same as 
before, I think line #7 changed a bit (missing my_perl = ...). See the 
attachement for the new valgrind-output.

(gdb) bt
#0  0x40734d9c in gtk_path_bar_get_type () from /usr/lib/
#1  0x402d5ddc in g_main_context_wakeup () from /usr/lib/
#2  0x402d36c2 in g_main_depth () from /usr/lib/
#3  0x402d4748 in g_main_context_dispatch () from /usr/lib/
#4  0x402d4a80 in g_main_context_dispatch () from /usr/lib/
#5  0x402d5023 in g_main_loop_run () from /usr/lib/
#6  0x4070c8f3 in gtk_main () from /usr/lib/
#7  0x403f8492 in XS_Gtk2_main () from /usr/lib/perl5/auto/Gtk2/
#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 ()

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

what is the name of that folder?  does its name (or the names of its
children) contain any non-ascii characters?  how many files are in that

With the test I did tonight, I think we can rule out an influence of the 
directory's name or content: 
the testscript is located in /home/stephan/Work/imTuS/segv/. I started it from 
there and tried all different kinds (empty, .something, ...) of the 
directories in /home/stephan and almost always got a segfault. In the 
top-level-directory names in my home, there are no non-ascii characters.

But there are two other observations I made during this tests:

a) Selecting directories in /home/stephan/Work or Work/imTuS, I got *much* 
less segfaults than selecting dirs in /home/stephan.

b) When I start the test script not from /home/stephan/Work/imTuS/segv, but cd 
to like /home/stephan/Work and start it from there (so the working dir of the 
script is /home/stephan/Work), I am able to select any of the 
"100%-segfault"-directories in /home/stephan and don't get one single 

Seeing this, it seems to me that the segfault depends not on directory names 
or contents, but more on the relation of working directory and the selected 
directory -- although I understand that this is pretty vague and merely 
impossible to extract hard facts or infos from.

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

(gdb) bt
#0  0x40769d9c in gtk_path_bar_get_type () from

the valgrind output confirms that there's memory corruption,
specifically, using freed memory on the heap.  the fun part will be
tracking down where and why that actually occurs...

Puh, the thing is that I'm simply lacking any of the needed knowledge for this 
"fun part". Is this at all possible for you as you can't reproduce the 
segfault? Or, what can I learn and do to get it done?

The above script is so short and simple that I am stunned it can

heh.  try a script that merely creates a common dialog (one-liner) but
doesn't first call Gtk2->init.  it blows up almost immediately because
pango isn't initialized.  ;-)

Hmm, well, I still do hope to find that missing 'init' or something, but I'm 
afraid it's not that simple...:-(

I very much appreciate your help,


Attachment: 2005_04_01_valgrind.log.gz
Description: GNU Zip compressed data

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