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

Re: upgrade-porter-chroots on zelenka

2012-05-20 Thread Faidon Liambotis 
Hi,

On Sun, May 20, 2012 at 03:48:29PM +0200, Philipp Kern wrote:
> I just ran upgrade-porter-chroots on zelenka and got this in sid_s390x:
> 
> | Setting up texlive-base (2012.20120516-1) ...
> | mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEMAIN... 
> | mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN... 
> | mktexlsr: Updating /var/lib/texmf/ls-R... 
> | mktexlsr: Done.
> | /usr/bin/tl-paper: setting paper size for dvips to letter.
> | /usr/bin/tl-paper: setting paper size for dvipdfmx to letter.
> | /usr/bin/tl-paper: setting paper size for xdvi to letter.
> | /usr/bin/tl-paper: setting paper size for pdftex to letter.
> | /usr/sbin/update-language-dat: cannot duplicate fd 3 to fd 0: Bad file 
> descriptor
> | 
> | malloc: ../bash/execute_cmd.c:3673: assertion botched
> | free: called with already freed block argument
> | Aborting...
>  
> We see this sometimes on the buildds, too (also on plain s390).  Giving it 
> back
> mostly solves the problem.  In this case the postinst of texlive-base hangs 
> due
> to update-language-dat.  I cannot kill the process in question and Ctrl-C does
> not work.  I guess that chroot will need manual attention and possibly 
> cleanup.

Killed & run apt-get install -f, everything seems good there.

Care to report a bug? :-)

Thanks,
Faidon


-- 
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/20120520140326.ga17...@tty.gr

upgrade-porter-chroots on zelenka

2012-05-20 Thread Philipp Kern 
Hi,

I just ran upgrade-porter-chroots on zelenka and got this in sid_s390x:

| Setting up texlive-base (2012.20120516-1) ...
| mktexlsr: Updating /var/lib/texmf/ls-R-TEXLIVEMAIN... 
| mktexlsr: Updating /var/lib/texmf/ls-R-TEXMFMAIN... 
| mktexlsr: Updating /var/lib/texmf/ls-R... 
| mktexlsr: Done.
| /usr/bin/tl-paper: setting paper size for dvips to letter.
| /usr/bin/tl-paper: setting paper size for dvipdfmx to letter.
| /usr/bin/tl-paper: setting paper size for xdvi to letter.
| /usr/bin/tl-paper: setting paper size for pdftex to letter.
| /usr/sbin/update-language-dat: cannot duplicate fd 3 to fd 0: Bad file 
descriptor
| 
| malloc: ../bash/execute_cmd.c:3673: assertion botched
| free: called with already freed block argument
| Aborting...
 
We see this sometimes on the buildds, too (also on plain s390).  Giving it back
mostly solves the problem.  In this case the postinst of texlive-base hangs due
to update-language-dat.  I cannot kill the process in question and Ctrl-C does
not work.  I guess that chroot will need manual attention and possibly cleanup.

Kind regards
Philipp Kern


signature.asc
Description: Digital signature

Re: Graphical installer for s390(x)?!

2012-05-20 Thread Philipp Kern 
Cyril,

am Sun, May 20, 2012 at 01:18:39AM +0200 hast du folgendes geschrieben:
> Given we have both of them on s390, I guess having both in sync (either
> way) is the way to go. Please tell me what you prefer.

I don't think we need xserver udebs at this point.

> (Looking at current debian-installer.git, I see no g-i image at all
> for s390* anyway. But who am I to know? ;))

Yeah, there's no such thing as g-i.  Theoretically there could be in the
future, if I understand it correctly, by using kvm on s390x.  Because that
would give you some sort of framebuffer.  But with native hardware: no
graphics.  (Unless g-i would support some sort of network-console with VNC.
But that would entail a huge initrd I presume.)

Kind regards
Philipp Kern


signature.asc
Description: Digital signature