Re: debugging gtk2-perl [was Re: GnomeAbout]

along the same vien, but not all that useful in this exact case. the -d option
on the perl command line sends perl into debug mode which behaves much like
debugging c with gdb.

those of you who have used gdb know that it can be useful, but a pain in the
a$$ for anything non-trivial. i would suggest tying one of the gui front ends
for gdb, personally i use ddd. what's even better is that after a switch is
flipped in ddd's options/preferences you can debug perl programs in it. if you
havn't tried it before give it a whirl. it's very usefull when you want to see
what's going on in your perl program.

unfortunately you can't jump back and forth between perl and c so debugging xs
wrappers isn't an option. if there's something/some way out there that can
handle such a case i'd love to hear about it. i would guess that you might be
able to manage it by attaching gdb/ddd to an already running process, but i've
never tried.


muppet said:

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
When I display the GnomeAbout once, than close it and come back I get :

(MoviXMaker:3988): Gtk-CRITICAL **: file gtkcontainer.c: line 1274
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
$ (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.

gtk-perl-list mailing list
gtk-perl-list gnome org

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