Re: haskell package build corruptions

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.