Hello, Michael Kelly, le dim. 15 févr. 2026 19:06:55 +0000, a ecrit: > On 04/01/2026 21:07, Samuel Thibault wrote: > > Hello, > > > > Michael Kelly, le dim. 04 janv. 2026 20:28:42 +0000, a ecrit: > > > stress-ng: fail: [3947] vm: detected 141733920769 bit errors while > > > stressing memory > > > stress-ng: fail: [3984] vm: detected 2 bit errors while stressing memory > > > > > > That's the good news. The bad news is that I suspect the cause is related > > > to > > > the handling of the signals which are used to terminate the stress-ng > > > worker > > > (oomable child). > > That'd still be useful to fix :) > > > > I'm seeing corruption issues with the haskell ghc compiler, see > > > > https://buildd.debian.org/status/fetch.php?pkg=ghc&arch=hurd-amd64&ver=9.10.3-1&stamp=1767477002&raw=0 > > > > I have to disable preemption to get the x86_64 build going, while the > > i386 build goes fine. > > Has the 'pending signal handling' fix helped with the building of the ghc > package ?
I believe it has helped, yes. 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 hadn't had any luck reproducing these memory/disk corruption issues whilst > specifically trying to find a test case. Ok :/ > I did however see a similar result whilst compiling gnumach locally > one time since then including the output: > > ./kern/mach.server.h:1:2: error: stray ‘@’ in program > 1 | #ifndef _mach_server_ > | ^ > ./kern/mach.server.h:1:3: warning: null character(s) ignored > 1 | #ifndef _mach_server_ > | ^ > ./kern/mach.server.h:1:5: error: stray ‘\1’ in program > 1 | #ifndef _mach_server_ > | ^ Yes, that's really like it. > The compilation succeeded normally upon immediately resuming the build. > > I'd like to start working on this again. Is it possible for someone like > myself to search all of the hurd build logs to look for instances of similar > compilation issues? It's not listed publicly. The thing is: it's usually *not* the package that gets an error that is the trigger for the issue, it's rather the package that was built before. My gut feeling on this is that it's large builds that trigger it. Samuel
