Re: Problems on AMD64 with Glib module

["muppet" <scott asofyet org>]

Jacek Konieczny said:
> I am porting PLD Linux Distribution to AMD64 platform (also known as x86_64)
> and I have proble with Glib perl module, version 1.020.

great to hear from you.


> It builds fine, but fails on make test, like this:

ah, the wonders of automated regression testing!


> t/9....Use of uninitialized value in ref-to-glob cast at t/9.t line 80, <IN>
> chunk 1.

line 80 is:

                        if (eof $_[0]) {

basically, the IO watch receives a file descriptor and a condition flag, and
this line is supposed to test for end of file on the file descriptor.

note i said file descriptor, not file handle.  the doc for eof() in perlfunc
says it works on file handles, but this code works on a file descriptor for
me.  the value returned for the IOChannel argument is a file descriptor
because that's what i can get from GLib.  if you know a way to look up the
PerlIO structure corresponding to a file descriptor, i'd love to hear it (it
would be really nice to use normal file handles with the IO watch stuff
instead of requiring file descriptors).

from your error message, it sounds like the version of perl you are using is
trying to interpret the file descriptor as a reference.  is it really a
reference, or is it an integer?

try uncommenting the Data::Dumper print on line 76 of t/9.t and running the
script directly (e.g., perl -I blib/lib -I blib/arch t/9.t).  on my system, it
prints:

  $VAR1 = [
            6,
            bless( do{\(my $o = 1)}, 'Glib::IOCondition' )
          ];



> ok
> t/a....# Looks like you planned 8 tests but ran 7 extra.

that test  exercises the log message stuff, and therefore counts warnings, and
you're probably getting extra ones.  if you would be so kind, please run that
test directly (as above) and post its output.

> dubious
>         Test returned status 7 (wstat 1792, 0x700)
> Scalar found where operator expected at (eval 155) line 1, near "'int'
> $__val"
>         (Missing operator before   $__val?)

this is weird stuff that comes out of newer Test::Harnesses, and seems to
accompany core dumps.  unfortunately, it's hard to reproduce directly, because
Test::Harness runs the scripts a little differently that you do on the command
line.



> A lot of software fails on AMD64 because problems reported by compiler
> via its warnings, usually about bad pointer or int-to-pointer conversion,
> were not fixed just because they are not actually problems on developer's
> platform.

you try to write portable code, but you never find out if it really is until
you try to run it somewhere else.

> I found one _very_bad_ piece of code in Glib module, which assumed that
> pointer can fit into 32-bit iteger (on AMD64 it won't fit). I fixed it
> so compiler doesn't complain, but I am not sure if I did it right. I don't
> know perl internals well enough.

Perl guarantees that an IV (i suppose actually a UV) is big enough to hold a
pointer.  in order to pass opaque pointers around via Perl in a couple of
places (e.g., Glib::Object::new_from_pointer) we use unsigned values -- it
should be UV instead of guint32, though.  your patch replaces it with gpointer
and a typemap -- nice touch. ;-)



> Compiler doesn't warn me any more, but the test still doesn't pass, so
> probably the problem is somhere else. Any hints?

there are probably bits of code which assume pointer/int samesizeness but
which do not trigger compiler warnings.  are you using the "-Wall -W" flags to
GCC?  (GCC will warn about nearly every xsub having an unused parameter named
"cv", but that's unavoidable.)



> My warning-killer patch is attached.

thanks.  doubtless, you will find similar problems in all of the Gtk2-Perl
modules, once you get past Glib.



-- 
muppet <scott at asofyet dot org>