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
