Test failure in i686

[ericonr]

Hi, as part of packaging tectonic for Void Linux, we run testuites for the package, which led us to notice an issue with the testuite on i686 (glibc, so nothing out of the ordinary):

Running target/i686-unknown-linux-gnu/release/deps/tex_outputs-8a48d0397862c30c

running 20 tests
test a4paper ... ok
test md5_of_hello ... ok
test file_encoding ... ok
test pdfimages ... ok
test pdfoutput ... ok
test prim_creationdate ... ok
test prim_filedump ... ok
test prim_filemoddate ... ok
test prim_filesize ... ok
test issue393_ungetc ... ok
test redbox_png ... ok
test synctex ... ok
test tectoniccodatokens_errinside ... ok
test otf_basic ... FAILED
test tectoniccodatokens_noend ... ok
test tectoniccodatokens_ok ... ok
test tex_logo ... ok
test the_letter_a ... ok
test negative_roman_numeral ... ok
test unicode_file_name ... ok

failures:

---- otf_basic stdout ----
thread 'otf_basic' panicked at 'difference in otf_basic.xdv; contents saved to disk', tests/util/mod.rs:198:9
stack backtrace:
   0: rust_begin_unwind
   1: std::panicking::begin_panic_fmt
   2: tex_outputs::util::ExpectedInfo::test_data
   3: tex_outputs::util::ExpectedInfo::test_from_collection
   4: tex_outputs::TestCase::go
   5: core::ops::function::FnOnce::call_once
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.


failures:
    otf_basic

test result: FAILED. 19 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out

This happens only with i686, x86_64 is fine. Could be i686 only, or could be 32-bit related.

[pkgw]

Thank you for reporting. It's not obvious to me what's happening here but I wouldn't be shocked if something 32-bit-related has snuck in.

A good first step would be adding a CI build that reproduces the problem. This can be a bit annoying to do for Tectonic since we rely on external libraries, so you can't use a bare-bones cross-compilation environment, but for a platform like i686 there shouldn't be anything tricky to do, just a matter of getting the pieces together.

[pkgw]

expected.txt
observed.txt

Using dviasm, I can get an analysis of the differences between the expected XDV file and the observed result on i686.

Some of the differences seem to involve a reordering of commands:

--- expected.txt        2021-03-20 20:08:09.953033700 -0400
+++ observed.txt        2021-03-20 20:08:24.740136985 -0400
@@ -31,28 +31,28 @@
     setglyphs: 23.258896pt gid499(0pt) gid72(5.564789pt) gid66(8.841034pt) gid70(12.117264pt) gid50(18.019318pt)
     w0:
     setglyphs: 24.632019pt gid105(0pt) gid63(4.589142pt) gid66(11.141617pt) gid98(14.417862pt) gid500(19.067230pt)
-    w0:
-    setglyphs: 22.933670pt gid114(0pt) gid66(8.515808pt) gid105(11.792053pt) gid63(16.381195pt)
     x: 3.629761pt
+    setglyphs: 22.933670pt gid114(0pt) gid66(8.515808pt) gid105(11.792053pt) gid63(16.381195pt)
+    w0:
     setglyphs: 36.701111pt gid50(0pt) gid77(5.239578pt) gid81(11.792053pt) gid109(17.694107pt) gid59(24.246582pt) gid63(30.148636pt)
     w0:

Others seem to involve small floating-point differences (ruh roh):

@@ -94,7 +94,7 @@
     w0:
     setglyphs: 27.197601pt gid105(0pt) gid28(4.589142pt) gid70(10.491196pt) gid50(16.393250pt) gid92(21.632812pt)
     right: 5.485703pt
-    setglyphs: 26.197876pt gid113(0pt) gid50(11.129578pt) gid72(16.369156pt) gid72(19.645401pt) gid45(22.921631pt)
+    setglyphs: 26.197876pt gid113(0pt) gid50(11.129578pt) gid72(16.369156pt) gid72(19.645386pt) gid45(22.921631pt)
     right: 4.030899pt
     setglyphs: 7.865387pt gid66(0pt) gid105(3.276245pt)
     w0:

Note that most of the test cases work, but not otf_basic, which suggests that the use of native system fonts is somehow injecting this dependency on the pointer width here.

[pkgw]

On my machine the following minimal testcase causes a difference between x86_64 and i686 output that looks like a floating-point rounding issue:

\font\x="[lmroman12-regular]"
\x breaking
\bye

Leads to the following difference:

--- shortest.expected.txt	2021-03-20 21:21:56.184977760 -0400
+++ shortest.observed.txt	2021-03-20 21:22:01.614015762 -0400
@@ -26,7 +26,7 @@
   push:
     right: 20pt
     fnt: "lmroman12-regular" (10pt) at 12.044998pt
-    setglyphs: 44.241272pt gid35(0pt) gid96(6.552475pt) gid50(11.141617pt) gid28(16.381195pt) gid70(22.283249pt) gid66(28.510513pt) gid77(31.786758pt) gid59(38.339233pt)
+    setglyphs: 44.241287pt gid35(0pt) gid96(6.552475pt) gid50(11.141617pt) gid28(16.381195pt) gid70(22.283249pt) gid66(28.510513pt) gid77(31.786758pt) gid59(38.339233pt)
   pop:
 pop:
 down: 24pt

If the root cause really is different floating-point behavior, this might be unfixable; ... but note that the original test currently passes on a good selection of non-x86 platforms. The difference in the XDV files here is a single bit difference in the setglyphs width.

[pkgw]

I've identified at least one place that seems to introduce the possibility of floating-point roundoff errors differing between i686 and x86_64. In xetex-XeTeXFontInst.cpp, I have the following debugging code:

    if (os2Table) {                                                                                                     
        m_capHeight = unitsToPoints(os2Table->sCapHeight);                                                              
        printf("CAPHEIGHT: %d %d %.18e %.18e => %.18e\n", (int) os2Table->sCapHeight, (int) m_unitsPerEM, (float) os2Ta\
ble->sCapHeight, m_pointSize, m_capHeight);                                                                             
        m_xHeight = unitsToPoints(os2Table->sxHeight);                                                                  
    }

The definition of unitsToPoints is (xetex-XeTeXFontInst.h):

    float unitsToPoints(float units) const                                                                              
    {                                                                                                                   
        return (units * m_pointSize) / (float) m_unitsPerEM;                                                            
    }

Evaluating the above testcase on 64-bit, I get output that includes:

CAPHEIGHT: 683 1000 6.830000000000000000e+02 1.204499816894531250e+01 => 8.226733207702636719e+00

On 32-bit in the same place I get:

CAPHEIGHT: 683 1000 6.830000000000000000e+02 1.204499816894531250e+01 => 8.226734161376953125e+00

The difference is minor, but big enough that I could imagine a roundoff error accumulating and resulting in a difference that emerges into the fixed-point code.

[pkgw]

OK, I think this will be fixed in #758.

[ericonr]

Yay, that's great :)

I will be glad to see CI completely green next time we update the package! Thanks 😊

[pkgw]

Looks like I need to figure out some new Windows failure that has popped up before I can merge #758, but we're almost there. Unfortunately I don't have a convenient way to debug the Windows stuff but I'll figure something out.

[pkgw]

The new Windows failure seems to have magically gone away with the latest Rust release, so I was able to merge the fix! I'll take it.

This issue won't be truly fixed until I release a new version of the tectonic_xetex_layout crate. I hope to clear the decks of a lot of backlogged Tectonic work soon, but I'm not sure exactly when that will be.

[ericonr]

No worries! Thanks a lot :D

Feel free to close the issue, unless you want to track it.

[pkgw]

This should be fixed as of the 0.5.0 release.