groff
[Top][All Lists]
Advanced

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

Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4


From: Deri
Subject: Re: [groff] 1.22.4.rc4 - Final RC before official 1.22.4
Date: Fri, 07 Dec 2018 00:09:20 +0000

On Thursday, 6 December 2018 20:45:31 GMT Ingo Schwarze wrote:
> Hi Deri, hi Bertrand,
> 
> i found out more about why the mom test is failing on Solaris 11.
> It turns out not just the test is broken, but there is likely a
> portability issue in gropdf(1).
> 
> I see this in the build log:
> 
>     GROFF    contrib/mom/examples/typesetting.pdf
>   Negative length at
> /home/schwarze/groff-1.22.4.rc4p1.solaris11/build/gropdf line 2430.
>     GROFF    contrib/mom/examples/slide-demo.pdf
> 
> Comparing the resulting file typesetting.pdf to the correct version built
> on Linux, it turns out the version built on Solaris 11 is truncated.
> It looks like gropdf(1) simply dies half-way through processing the
> file with the above fatal error message printed by the Perl interpreter.
> 
> Here is the beginning of the text that is missing from the outpiut file:
> 
>   24 0 obj << /Contents [25 0 R  ]
>   /Group << /CS /DeviceRGB
>   /S /Transparency
> 
>   /MediaBox [0 0 612 792 ]
>   /Parent 2 0 R
>   /Type /Page
> 
>   endobj
>   25 0 obj << /Filter /FlateDecode
>   /Length 4239
> 
>   stream
>   [...]
> 
>  $ wc typesetting.pdf.*
>     2191   16414  504021 typesetting.pdf.linux
>       29     126    3566 typesetting.pdf.solaris
> 
> Line 2430 in gropdf.pl is:
> 
>                 my $chk=read($F,$data,$sl);
> 
> so apparently
> 
>                 my $sl=unpack('L',$hdr);
> 
> yields a number so large that it wraps around to negative
> when passed to read(3p).
> 
> So i surrounded the suspicious unpack() call with debugging
> output as follows:
> 
>       printf STDERR "hdr: %d %d %d %d\n",
>           ord($hdr), ord(substr $hdr, 1),
>           ord(substr $hdr, 2), ord(substr $hdr, 3);
>       my $sl=unpack('L',$hdr);
>       print STDERR "sl: $sl\n";
> 
> The output is:
> 
>     GROFF    contrib/mom/examples/typesetting.pdf
>   hdr: 176 6 0 0
>   sl: 2953183232
>   Negative length at
> /home/schwarze/groff-1.22.4.rc4p1.solaris11/build/gropdf line 2435.
>     GROFF    contrib/mom/examples/slide-demo.pdf
> 
> I guess the length is supposed to be 176 + 2 * 256 = 688 (little endian)
> but is instead calculated as 176 * 256^3 + 6 * 256^2 = 2953183232
> (big endian).
> 
> Frankly, that looks like an endianness bug.  Did anybody ever test
> gropdf(1) on a big-endian platform?
> 
> Not sure what to do about it, though, since i don't really understand
> the code in the GetChunk() function...
> 
> Yours,
>   Ingo

Hi Ingo, 

I only have access to intel or arm. Please can you test changing line 2428 to:-

                my $sl=unpack('L>',$hdr);

I.E. Adding the ">" symbol. I have checked that "L<" works here. If this cures 
the error then I 
need to find a way of determining which to use.

What does this produce:-

perl -MConfig -e 'print "$Config{byteorder}\n";'

On intel and arm I see "12345678".

Please could you investigate for me and any advice on whether there is a 
configure test which 
could pass me the endianness of the system. Thanks for doing these tests.

Cheers 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]