Hello Samuel,
On 15/02/2026 20:51, Samuel Thibault wrote:
I'm however still seeing issues in ghc packages, with bogus .so
files getting generated. E.g. I have triggered yet another build for
haskell-hedgehog-classes, which produced bogus files twice. They are
available on
http://snapshot.debian.org/package/haskell-hedgehog-classes/0.2.5.4-3/
the various libghc-hedgehog-classes-dev_0.2.5.4-3*_hurd-amd64.deb files.
In them, the
usr/lib/haskell-packages/ghc/lib/x86_64-hurd-ghc-9.10.3-bf23/libHShedgehog-classes-0.2.5.4-G7tsQia20R08oTHeaC1Vez-ghc9.10.3.so
file shows a bogus R_X86_64_NONE relocation among the R_X86_64_RELATIVE
relocations or along the R_X86_64_64 relocations. We then get assertions
failures while loading them.
I've spent quite some time on this with little to show. I've tried
various levels of I/O (with read and write) concurrently with repeated
builds of libHShedgehog-classes with no failures. I ran that sequence
for around 30 successful builds until my virtual machine locked up with
a panic:
panic ../vm/vm_page.c:1618: vm_page_alloc_pa: vm_page: privileged thread
unable to allocate page
This panic is unrelated and something that I
have recently witnessed occasionally after long stress-ng tests. I think
that I need to divert attention to fixing this really.
The corruption isn't entirely random. These are the 'od' differences
between the broken shared library from the 'snapshot.debian.org' above
and one from a local build that doesn't show the R_X86_64_NONE elf entries:
$ diff working/hexdump broken/hexdump | grep '<'
< 024050 485f 6465 6567 6f68 7a67 4369 616c 7373
< 024070 7a5f 7464 5463 6972 6c70 3165 635f 6f6c
< 024ff0 6800 6465 6567 6f68 7a67 636d 616c 7373
< 066050 7098 001b 0000 0000 0008 0000 0000 0000
< 066070 0008 0000 0000 0000 5fe0 001b 0000 0000
< 066ff0 7f0b 001b 0000 0000 7f38 001b 0000 0000
< 0a0050 0000 0000 0000 0000 24d8 001a 0000 0000
< 0a0070 2598 001a 0000 0000 0001 0000 01f0 0000
< 0a0ff0 0001 0000 01f0 0000 0000 0000 0000 0000
< 120050 f024 8d48 7705 08d4 4900 4489 f824 8d49
< 120070 90ff c749 8885 0003 6800 0000 4100 65ff
< 120ff0 001e 0000 0000 0000 8b48 0875 8949 48de
Each 16 byte sequence above is completely replaced by zero in the broken
library. There is a consistent pattern of wrongly finding zero at page
offsets 0x50, 0x70 and 0xff0. I don't imagine there is anything generic
to conclude from these particular offsets but the consistency is perhaps
relevant.
What version of gnumach do the buildd machines run ?
Are there any other packages available to download that also have
corrupted content ?
Mike.
