Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.

2012-05-20 Thread Philipp Kern 
On Sun, May 20, 2012 at 10:37:00PM +0200, Bastian Blank wrote:
> On Sun, May 20, 2012 at 10:22:58PM +0200, Philipp Kern wrote:
> > you cannot reinterpret a size_t as an int.  size_t might be unsigned, might
> > have another length, etc.  On 64bit big endian you fill the top bits and
> > leave the lower ones untouched, because size_t is 64bit.  So yeah, that code
> > was broken.  (nbd had something similar, glib too. I don't know why it only
> > turns up with 64bit big endian.)
> Because on little endian 64bit, it touches the lower bytes.

Yeah, but that assumes that the other ones are 0?  Or ok, maybe it's just
working when going from size_t to int, because it's truncation, but it
shouldn't work for the other way round?

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.

2012-05-20 Thread Bastian Blank 
On Sun, May 20, 2012 at 10:22:58PM +0200, Philipp Kern wrote:
> you cannot reinterpret a size_t as an int.  size_t might be unsigned, might
> have another length, etc.  On 64bit big endian you fill the top bits and
> leave the lower ones untouched, because size_t is 64bit.  So yeah, that code
> was broken.  (nbd had something similar, glib too. I don't know why it only
> turns up with 64bit big endian.)

Because on little endian 64bit, it touches the lower bytes.

Bastian

-- 
Bones: "The man's DEAD, Jim!"


-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520203700.ga23...@wavehammer.waldi.eu.org

Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.

2012-05-20 Thread Cyril Brulebois 
Hi Niko,

and thanks for the quick follow-up.

Niko Tyni  (20/05/2012):
> See the attached patch, which just makes 'len' an int and removes the
> problematic pointer cast. I wonder if the STRLEN cast on becomes an
> issue, though. Is it possible that an int doesn't fit into a size_t
> variable somewhere?

If you were asking for a test-build, the answer is: no more FTBFS on s390x.

On the int/size_t thingy, quoting [1]:
| ISO/IEC 9899:1990, Programming Languages - C (ISO C) left the definition
| of the short int, the int, the long int, and the pointer deliberately
| vague to avoid artificially constraining hardware architectures that
| might benefit from defining these data types independent from the other.
| The only constraints were that ints must be no smaller than shorts, and
| longs must be no smaller than ints, and size_t must represent the
| largest unsigned type supported by an implementation. It is possible,
| for instance, to define a short as 16 bits, an int as 32 bits, a long as
| 64 bits and a pointer as 128 bits. The relationship between the
| fundamental data types can be expressed as:
|
| sizeof(char) <= sizeof(short) <= sizeof(int) <= sizeof(long) = 
sizeof(size_t) 

 1. http://www.unix.org/whitepapers/64bit.html

Thanks for your time.

Mraw,
KiBi.


signature.asc
Description: Digital signature

Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.

2012-05-20 Thread Philipp Kern 
Niko,

am Sun, May 20, 2012 at 10:59:28PM +0300 hast du folgendes geschrieben:
> It's a pointer cast in XML::LibXML::Document::toStringHTML, in LibXML.xs
> around line 2939.
> 
> STRLEN len = 0;
> [...]
> htmlDocDumpMemory(self, &result, (int*)&len);
> [...]
> RETVAL = newSVpvn((char *)result, (STRLEN)len);
> 
> (STRLEN is defined as a size_t via /usr/lib/perl/5.14/CORE/perl.h)
> 
> See the attached patch, which just makes 'len' an int and removes the
> problematic pointer cast. I wonder if the STRLEN cast on becomes an
> issue, though. Is it possible that an int doesn't fit into a size_t
> variable somewhere?

you cannot reinterpret a size_t as an int.  size_t might be unsigned, might
have another length, etc.  On 64bit big endian you fill the top bits and
leave the lower ones untouched, because size_t is 64bit.  So yeah, that code
was broken.  (nbd had something similar, glib too. I don't know why it only
turns up with 64bit big endian.)

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.

2012-05-20 Thread Niko Tyni 
On Sun, May 20, 2012 at 07:46:24PM +0300, Niko Tyni wrote:
> On Sun, May 20, 2012 at 02:00:46AM +0200, Cyril Brulebois wrote:
> > Source: libxml-libxml-perl
> > Version: 1.98+dfsg-1
> > Severity: important
> 
> > your package FTBFS on s390x, in the test suite:

> >   
> > https://buildd.debian.org/status/package.php?p=libxml-libxml-perl&suite=sid

>  Out of memory!
>  # Looks like you planned 43 tests but ran 41.
>  # Looks like your test exited with 1 just after 41.
>  t/12html.t .. 
>  Dubious, test returned 1 (wstat 256, 0x100)
>  Failed 2/43 subtests 

> It happens on ppc64 and sparc64 as well, as seen at
> buildd.debian-ports.org. I suppose that means it's broken on all big
> endian 64-bit platforms.

It's a pointer cast in XML::LibXML::Document::toStringHTML, in LibXML.xs
around line 2939.

STRLEN len = 0;
[...]
htmlDocDumpMemory(self, &result, (int*)&len);
[...]
RETVAL = newSVpvn((char *)result, (STRLEN)len);

(STRLEN is defined as a size_t via /usr/lib/perl/5.14/CORE/perl.h)

See the attached patch, which just makes 'len' an int and removes the
problematic pointer cast. I wonder if the STRLEN cast on becomes an
issue, though. Is it possible that an int doesn't fit into a size_t
variable somewhere?
-- 
Niko Tyni   nt...@debian.org
>From c8cc2e7c69eeba03de40499023698db0aaf5dd6a Mon Sep 17 00:00:00 2001
From: Niko Tyni 
Date: Sun, 20 May 2012 22:32:31 +0300
Subject: [PATCH] Fix test failures on 64-bit big endian platforms

As seen in , t/12html.t is crashing
on 64-bit big endian platforms with

>  Out of memory!
>  # Looks like you planned 43 tests but ran 41.
>  # Looks like your test exited with 1 just after 41.
>  t/12html.t ..
>  Dubious, test returned 1 (wstat 256, 0x100)
>  Failed 2/43 subtests

STRLEN has 64 bits here and int has 32, so the (int*) cast in
XML::LibXML::Document::toStringHTML() makes htmlDocDumpMemory() store
the 32-bit length of the result into a 64-bit variable.  Depending on
the endianness, it either works OK (LE) or corrupts the variable (BE)

Just use an 'int' instead, and cast it to an STRLEN later in the
newSVpvn() call.

TODO: Is it possible that an int doesn't fit into an STRLEN variable
somewhere? perlguts(1) says:

  "STRLEN" is an integer type (Size_t, usually defined as size_t in
  config.h) guaranteed to be large enough to represent the size of any
  string that perl can handle.
---
 LibXML.xs |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/LibXML.xs b/LibXML.xs
index 8ac23bf..581cc48 100644
--- a/LibXML.xs
+++ b/LibXML.xs
@@ -2930,13 +2930,13 @@ toStringHTML(self)
XML::LibXML::Document::serialize_html = 1
 PREINIT:
 xmlChar *result=NULL;
-STRLEN len = 0;
+int len = 0;
 PREINIT_SAVED_ERROR
 CODE:
 PERL_UNUSED_VAR(ix);
 xs_warn( "use no formated toString!" );
 INIT_ERROR_HANDLER;
-htmlDocDumpMemory(self, &result, (int*)&len);
+htmlDocDumpMemory(self, &result, &len);
 CLEANUP_ERROR_HANDLER;
 REPORT_ERROR(0);
 
-- 
1.7.10

Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.

2012-05-20 Thread Niko Tyni 
On Sun, May 20, 2012 at 02:00:46AM +0200, Cyril Brulebois wrote:
> Source: libxml-libxml-perl
> Version: 1.98+dfsg-1
> Severity: important

> your package FTBFS on s390x, in the test suite:
> | Test Summary Report
> | ---
> | t/12html.t(Wstat: 256 Tests: 41 Failed: 0)
> |   Non-zero exit status: 1
> |   Parse errors: Bad plan.  You planned 43 tests but ran 41.
> | Files=51, Tests=2419,  9 wallclock secs ( 0.50 usr  0.11 sys +  4.82 cusr  
> 0.64 csys =  6.07 CPU)
> | Result: FAIL
> | Failed 1/51 test programs. 0/2419 subtests failed.
> | make[2]: *** [test_dynamic] Error 255
> 
> Full build logs:
>   https://buildd.debian.org/status/package.php?p=libxml-libxml-perl&suite=sid

FWIW, the test is dying with 'Out of memory!':

 t/10ns.t  ok
 t/11memory.t  skipped: developers only (set 
MEMORY_TEST=1 to run these tests)
 Out of memory!
 # Looks like you planned 43 tests but ran 41.
 # Looks like your test exited with 1 just after 41.
 t/12html.t .. 
 Dubious, test returned 1 (wstat 256, 0x100)
 Failed 2/43 subtests 
 t/13dtd.t ... ok

> I'm putting the s390 list in X-Debbugs-Cc, maybe somebody will know.

It happens on ppc64 and sparc64 as well, as seen at
buildd.debian-ports.org. I suppose that means it's broken on all big
endian 64-bit platforms.
-- 
Niko Tyni   nt...@debian.org


-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120520164624.GA9993@madeleine.local.invalid

Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.

2012-05-19 Thread Cyril Brulebois 
Source: libxml-libxml-perl
Version: 1.98+dfsg-1
Severity: important

Hi,

your package FTBFS on s390x, in the test suite:
| Test Summary Report
| ---
| t/12html.t(Wstat: 256 Tests: 41 Failed: 0)
|   Non-zero exit status: 1
|   Parse errors: Bad plan.  You planned 43 tests but ran 41.
| Files=51, Tests=2419,  9 wallclock secs ( 0.50 usr  0.11 sys +  4.82 cusr  
0.64 csys =  6.07 CPU)
| Result: FAIL
| Failed 1/51 test programs. 0/2419 subtests failed.
| make[2]: *** [test_dynamic] Error 255

Full build logs:
  https://buildd.debian.org/status/package.php?p=libxml-libxml-perl&suite=sid

I noticed this FTBFS because it is responsible for the uninstallability
of the following packages in testing, on the s390x architecture:
  libxml-atom-fromowl-perl
  libnet-amazon-s3-tools-perl
  xmltv
  torrus-common
  jirc
  ripit
  libhtml-html5-parser-perl
  libxml-simpleobject-libxml-perl
  xmltv-util
  movabletype-opensource
  lemonldap-ng
  libxml-atom-service-perl
  librdf-microturtle-perl
  libcgi-xmlapplication-perl
  libgeo-googleearth-pluggable-perl
  […]

I won't list them all, too many of them. ;)

I'm putting the s390 list in X-Debbugs-Cc, maybe somebody will know.

Mraw,
KiBi.



-- 
To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/2012052046.10044.16819.report...@kashyyyk.rennes.ariadnext.com