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 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.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 below?
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: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...)
[code] 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/libgtk-x11-2.0.so.0 #1 0x402d5ddc in g_main_context_wakeup () from /usr/lib/libglib-2.0.so.0 #2 0x402d36c2 in g_main_depth () from /usr/lib/libglib-2.0.so.0 #3 0x402d4748 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #4 0x402d4a80 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0 #5 0x402d5023 in g_main_loop_run () from /usr/lib/libglib-2.0.so.0 #6 0x4070c8f3 in gtk_main () from /usr/lib/libgtk-x11-2.0.so.0 #7 0x403f8492 in XS_Gtk2_main () from /usr/lib/perl5/auto/Gtk2/Gtk2.so #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 segfault.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 folder?
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 segfault! 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 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.0the 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 segfault.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, Stephan
Attachment:
2005_04_01_valgrind.log.gz
Description: GNU Zip compressed data