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

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



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   ntyni@debian.org
>From c8cc2e7c69eeba03de40499023698db0aaf5dd6a Mon Sep 17 00:00:00 2001
From: Niko Tyni <ntyni@debian.org>
Date: Sun, 20 May 2012 22:32:31 +0300
Subject: [PATCH] Fix test failures on 64-bit big endian platforms

As seen in <http://bugs.debian.org/673590>, 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


Reply to: