Living on the bleeding edge (a bug report)

[Bjarne Steinsbø <bosteins broadpark no>]

A bug report from the bleeding edge.

Summary:
 - making the (Gtk2) pods (in make install) fails with core dump from perl
 - a small bug in (Gtk2) t/t00.Gtk2 test number 2.  Scalar vs. list 
context.
 - some problem at line 87 in (Gtk) t/04.Gtk2 test number 4

More detailed report:

Looking through the ChangeLog of gtk+-2.3.0, I decided this this was 
something I wanted.  So I compiled and installed it.  Yep, I installed 
it in /usr/lib, replacing the stable version.  On purpose.

I also wanted the latest CVS version of gtk-perl, so I compiled it, or 
rather, I *tried* to compile it.  Compiling and installing the ExtUtils 
and Glib worked without a hitch.  When trying to compile Gtk2, my perl 
dumped core on me when trying to build the new pods.  Upgrading perl to 
5.8.1 (was previously running 5.8.0) did not fix the problem.  First of 
all I think this step should be done when running "make all", not be 
left for "make install".  I normally do the "make" as myself, and only 
switch to "root" when doing the install.  In this case, I end up with 
lots of files in the build-tree being owned by root, which I can't clean 
up afterwards with "make clean".  But OK.  Looking at the output files, 
I found that "TreeView.pod" had been generated, while 
"TreeViewColumn.pod" had a zero size.  This was when running the command 
in the perl debugger with trace on.  Strangely enough perl didn't dump 
core this time, instead it went into never-never-land after printing out

202:                    if ($ret)
203:                    {
Glib::GenPod::xsdoc2pod(/usr/lib/perl5/site_perl/5.8.1/i686-linux/Glib/GenPod.pm:204):
204:                            print "=head1 HIERARCHY\n\n$ret";
Glib::GenPod::xsdoc2pod(/usr/lib/perl5/site_perl/5.8.1/i686-linux/Glib/GenPod.pm:207):
207:                    $ret = podify_interfaces ($package);
Glib::GenPod::podify_interfaces(/usr/lib/perl5/site_perl/5.8.1/i686-linux/Glib/GenPod.pm:444):
444:            my @int;
Glib::GenPod::podify_interfaces(/usr/lib/perl5/site_perl/5.8.1/i686-linux/Glib/GenPod.pm:445):
445:            eval { @int = Glib::Type->list_interfaces (shift); 1; };
Glib::GenPod::podify_interfaces(/usr/lib/perl5/site_perl/5.8.1/i686-linux/Glib/GenPod.pm:445):
445:            eval { @int = Glib::Type->list_interfaces (shift); 1; };

It didn't dump core at all when running under the debugger.  Looks as if 
the problem has something to do with memory corruption.

I then did a "make pure_install" to get on with it.

Running the tests revealed some more problems.  There's a small bug in 
test 2 in t/00.Gtk2.  There's something going on with list vs. scalar 
context, where the sub-sub-version (0 in my case) is interpreted by the 
test module as the test result.  The included patch fixes it.

Test number 4 in t/04.Gtk2 fails with message from gtk+ :
Gtk-CRITICAL **: file gtkxembed.c: line 188 
(_gtk_xembed_send_focus_message): assertion `GDK_IS_WINDOW (recipient)' 
failed at t/04.GtkSocket-GtkPlug.t line 87.
I have no idea what this is.  Since focus might be involved, it might 
have something to do with the fact that I've set my window manager to 
use focus-follows-mouse (metacity now calls it "focus model : sloppy" 
:-) ?  A gtk+ bug?  I've seen the same error when installing a previous 
version from cvs, but running gtk+-2.2.4 instead of 2.3.0, so it's not 
2.3.0 specific.

Coming back to GenPod problem, I verified (hacking a copy of GenPod) 
that TreeViewColumn was indeed involved.  I tried the following little 
perl program (outside the build directory)

perl -MGtk2 -e '@int = Glib::Type->list_interfaces 
("Gtk2::TreeViewColumn");'

which  dumped core and

perl -d -MGtk2 -e '@int = Glib::Type->list_interfaces 
("Gtk2::TreeViewColumn");'

went into never-never-land.  This didn't happen with 'Gtk2::TreeView'.  
Looking at the xs code of Glib::GType, it worries my a bit that nobody 
seems to free the list returned by g_type_interfaces, but I don't know 
enough to say that this is the problem.  It could be something down in 
gtk_tree_view_column.

Otherwise things seem to go perfectly OK.  I won't exactly recommend 
running a test version of gtk+, but it seems to have worked out well for me.

Bjarne

--- cvs_gtk2-perl-xs/Gtk2/t/00.Gtk2.t   2003-09-22 02:04:24.000000000 +0200
+++ 00.Gtk2.t   2003-11-03 15:10:41.000000000 +0100
@@ -17,7 +17,7 @@
 
 #########################
 
-ok( Gtk2->get_version_info );
+ok( scalar @{[Gtk2->get_version_info]} );
 ok( Gtk2->check_version(0,0,0) eq 'Gtk+ version too new (major mismatch)' );
 ok( Gtk2->check_version(50,0,0) eq 'Gtk+ version too old (major mismatch)' );