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

["Ross McFarland" <rwmcfa1 neces com>]

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.

-rm

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
>> 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 ./movixmaker-2.pl 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 Gtk2.so or Gnome2.so, or, if we are unlucky, in  Glib.so or
> even libperl.so (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
> http://mail.gnome.org/mailman/listinfo/gtk-perl-list