Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.
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-perlsuite=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
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-perlsuite=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 nt...@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
Re: Bug#673590: libxml-libxml-perl: FTBFS on s390x: Failed 1/51 test programs. 0/2419 subtests failed.
Hi Niko, and thanks for the quick follow-up. Niko Tyni nt...@debian.org (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.
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.
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
