On 19 Feb 2026 18:55, Michael Kelly <[email protected]> wrote:
I found 2 packages from your rebuild list that have corrupted builds. Each package generates one shared library. I compared the 'od' dump of that library with the equivalent of a successful local build which shows a very similar pattern of offsets and 16 byte chunks being replaced by zeros. I haven't analysed all of the rebuild list but these 2 were built using libc0.3-dev (2.42-12):
I think it might be useful to summarise the current understanding in order to work out how to progress from here. There are 2 (possibly related) patterns of corruption:
1) Certain compilations refer to the contents of a header file that when parsed find corrupt contents. This presents as compilation failure with error reports like:
/usr/include/i386-gnu/bits/types/clock_t.h:1:3: error: stray ‘\2’ in program
This has previously been seen in qtcreator, sysprof and others. I found some errors like this from build logs as far back as 2024 so it's not a recent development. I've witnessed this on 1 occasion on my personal machine whilst compiling gnumach.
2) Many of the haskell library package builds are seemingly successful but actually result in corrupted build contents. The shared library that is built sometimes has 16 byte chunks replaced (or never written initially at all) with zeros. These are seen at one of 3 offsets within a page sized chunk of memory: 0x50, 0x70 and 0xff0. Despite building some of these packages many times I haven't seen this issue locally.
The double signal fix is included in libc0.3 (2.42-12). That helped the main haskell compiler (ghc) package build but hasn't helped with issue 2. Does issue 1 also still occur in builds made with the latest glibc?
The problems are seen on the buildd machines more frequently than on mine. This might be down to relatively poor performance of my machine or some subtle difference in the machine or software configuration.
It would make solving these problems simpler with a regularly failing test case. I wonder if there's anything that might be gained by trying to setup a test buildd machine even though it seems unlikely that would do much differently than just using sbuild or pbuilder directly?
Any other suggestions for what I might try to make progress?
Cheers,
Mike.
