debugging gtk2-perl [was Re: GnomeAbout]

On Thursday, July 3, 2003, at 11:41 AM, Pascal wrote:

This might be off-topic, but i'm wondering if it's gtk2-perl-xs related...
When I display the GnomeAbout once, than close it and come back I get :

(MoviXMaker:3988): Gtk-CRITICAL **: file gtkcontainer.c: line 1274 (gtk_container_foreach):
assertion `GTK_IS_CONTAINER (container)' failed
Usage: Gtk2::main_quit(class) at ./ line 163.

Sometimes, it justs SegFaults...

i don't see this in my code, but it may be that we're creating them in different ways.

i was going to say just "send me a copy of the offending code with instructions on how to reproduce the bug", but i figured other people might be interested in this sort of thing and not be able to send their code... so, i'll tell you what i'd do to track it down.

this is probably basic stuff for you C programmers on the list, but i've geared it for the perl programmers with little or no C experience.

the first thing is to find out where the segfault happened. to do this, you need to have debugging symbols turned on in the code in question (or else the information you get in the core dump is not very useful).

1. if you don't already have them, rebuild Gtk2 and Glib with debugging symbols turned on. you might wish to install them to another place so that you can use them just for debugging:

$ export PREFIX=~/tmp/debug-gtk2-perl
$ export PERL5LIB=$PREFIX/lib/perl5/site_perl
$ export PASTHRU_INC="-Wall -g" # PASTHRU_INC is used by the perl makefiles
$ (cd Glib && perl Makefile.PL PREFIX=$PREFIX && make install)
$ (cd Gtk2 && perl Makefile.PL PREFIX=$PREFIX && make install)
$ (cd Gnome2 && perl Makefile.PL PREFIX=$PREFIX && make install)

with warnings turned on, you'll see lots of warnings about unused variables; those mostly the ignored "class" arguments on class methods.

2. make sure that you will dump a core file when you segfault:

$ ulimit -c unlimited

3. run the program again, and make it segfault.

4. open the core file in gdb

$ gdb perl core.threadid

where threadid is actually the number of the process id of the thread that segfaulted. be careful to clean up, or you'll accumulate a zillion of these really quickly.

once in gdb, do

gdb> bt

to get a backtrace.

this should take you the very spot at which the segfault happened, probably within either or, or, if we are unlucky, in or even (for which you won't have any debugging information unless you built perl with -g as well). usually, the actual bug is not on that actual line, but maybe a few lines before or a stack frames away; the more insidious ones involve something getting set incorrectly in a completely unrelated section of code.

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