big-endian s390x: polygonToCells_reported.fuzzer_crash: t_assert failed at ./src/apps/testapps/testPolygonToCellsReportedExperimental.c:54, sz == 1, Expected output count

[df7cb]

The Debian package build for 4.2.0 fails on the big-endian s390x architecture:

12:28:01 test 101
12:28:01         Start 101: testPolygonToCellsReportedExperimental_test101
12:28:01 
12:28:01 101: Test command: /<<PKGBUILDDIR>>/obj-s390x-linux-gnu/bin/testPolygonToCellsReportedExperimental
12:28:01 101: Working Directory: /<<PKGBUILDDIR>>/obj-s390x-linux-gnu
12:28:01 101: Test timeout computed to be: 1500
12:28:01 101: polygonToCells_reported.fuzzer_crash: t_assert failed at ./src/apps/testapps/testPolygonToCellsReportedExperimental.c:54, sz == 1, Expected output count
12:28:01 101: TEST polygonToCells_reported
12:28:01 101/280 Test #101: testPolygonToCellsReportedExperimental_test101 ...***Failed    0.12 sec
12:28:01 polygonToCells_reported.fuzzer_crash: t_assert failed at ./src/apps/testapps/testPolygonToCellsReportedExperimental.c:54, sz == 1, Expected output count
12:28:01 TEST polygonToCells_reported

Full build log: https://jengus.postgresql.org/job/libh3-binaries/10/architecture=s390x,distribution=sid/console

This is the only test that is failing in this version. On 4.1.0, the tests were succeeding.

[isaacbrodsky]

Is this running on a real s390x machine or virtualized? Do you have instructions for running the tests on this architecture for debugging?

This test case came directly from a fuzzer, which is probably why it is not reproducing cleanly on other architectures. We can loosen the test assertions, remove the test, or try to rewrite the test.

[df7cb]

It's an actual s390x machine, hosted at https://linuxone.cloud.marist.edu/. I guess you could get an account there to spin up a test machine.

Good point about the fuzzer, I'll see if I can disable the test here.

[Scottcjn]

I reproduced this on a native big-endian POWER8 (ppc64) host (real hardware, not emulation) — same failure as the s390x build, so it's not s390x-specific.

Root cause is the test data: fuzzer_crash reinterprets the raw data[] byte array as LatLng doubles (verts = (LatLng *)data), so the decoded vertices depend on floating-point byte order. On big-endian the first vertex's latitude even decodes to NaN. maxPolygonToCellsSizeExperimental still succeeds (no crash) but returns sz = 3 instead of 1, which is what trips the sz == 1 assertion — confirming your hunch that the fuzzer-derived bytes just don't carry across architectures.

Opened #1182 to drop the non-portable assertion (keeping the calls that actually exercise the original crash path). Verified the full testPolygonToCellsReportedExperimental suite passes on the big-endian POWER8 host and still passes on little-endian.