Samuel,
On 18/07/2026 22:13, Samuel Thibault wrote:
Re,
Michael Kelly, le sam. 18 juil. 2026 21:35:50 +0100, a ecrit:
The corruptions that we have seen often follow the pattern having 16
bytes of zero at offsets 0x50, 0x70 and 0xff0 in 1 or more pages in
the file.
And I haven't seen such kind of corruptions in other builds, so that
leads me to believe this is really related to ghc's particular habit of
frequent timer signals.
Thanks for the details regarding the buildd configuration etc. I have
reconfigured my VM using 2Mb huge pages and will attempt the same on my
other machine using 1Gb pages when I bring it back home at the weekend.
This was the most notable difference that I could see in my setup.
It hasn't shown any of the corruption to the locally built libraries yet
though. The repeated build has however shown one result which could
potentially be valuable in that haskell-attoparsec fails its build tests
approximately 10% of the time running the test case described as 't_iter':
t_iter: FAIL
*** Failed! Falsified, Falsified (after 4 tests and 23 shrinks):
BP ["","\NUL\2053"] "\NUL\2053" "\NUL\2053"
4 /= 0
('\-3749',2) /= ('\-3904',2)
Use --quickcheck-replay="(SMGen 3451078120216687498
10201804171857947263,3)" to reproduce.
Use -p '$0=="tests.buf.t_iter"' to rerun this test only.
I've run the same test on a Linux debian13 VM which has the same
haskell-attoparsec package version (0.14.4) which succeeds for at least
1000 iterations. The ghc versions do however vary with Hurd at 9.10.3-3
and Linux at 9.6.6-4.
It might of course be totally unconnected to the corruption but it's the
only current lead. It might indicate a problem with the Hurd
nevertheless and merits investigation?
Cheers,
Mike.
