Hi,
I am recording a longstanding build/test failure observed on Debian
GNU/Hurd (hurd-i386). This identifies where the failure has been observed;
it does not establish that the problem is specific to Hurd. The affected
synchronization code is shared between platforms, and the root cause and
broader platform impact have not yet been established.
The 20260511+ds1-2 build on ironforge.sceen.net completes compilation and
linking, and test0 passes. During the build-time test suite, test1 runs:
./mbuffer -i test.tar -f -o test1.tar -o /dev/null -H
Here test.tar is generated by the upstream test suite and -H selects MD5.
The expected result is successful completion of both outputs and the hash
calculation, followed by the test's checksum comparison. Instead, mbuffer
aborts during the transfer:
mbuffer: mbuffer.c:366: syncSenders: Assertion `(buf != 0) || Terminate' failed.
make[1]: *** [Makefile:123: test1] Aborted (core dumped)
dh_auto_test: error: make -j1 check TESTSUITEFLAGS="-j1 --verbose" VERBOSE=1 returned exit code 2
make: *** [debian/rules:28: binary-arch] Error 255
Full build log (29 September 2026):
https://buildd.debian.org/status/fetch.php?pkg=mbuffer&arch=hurd-i386&ver=20260511%2Bds1-2&stamp=1790649819&raw=0
Selected environment details, taken from that log:
Build/host/machine architecture: hurd-i386
sbuild: 0.89.3
gcc-16: 16.2.0-2
libc0.3: 2.43-7~hurd.1
libgcrypt20: 1.12.4-2
This failure predates the adoption upload. The same test and assertion
also fail in these older hurd-i386 build logs:
20260511+ds1-1, 9 July 2026 (mbuffer.c:366):
https://buildd.debian.org/status/fetch.php?pkg=mbuffer&arch=hurd-i386&ver=20260511%2Bds1-1&stamp=1783641146&raw=0
20230301+ds1-1, 3 March 2023 (mbuffer.c:356):
https://buildd.debian.org/status/fetch.php?pkg=mbuffer&arch=hurd-i386&ver=20230301%2Bds1-1&stamp=1677833430&raw=0
This establishes that the symptom is longstanding, not which version
introduced it. The -2 adoption changes do not alter upstream code, the
Debian patch queue, build rules or test1.
One possible lead from static inspection is the reusable synchronization
barrier in syncSenders(): it calls pthread_cond_wait() once, without
rechecking a predicate or generation on return. POSIX permits spurious
wakeups, so a successful return alone does not establish that a new buffer
has been published. This is a hypothesis for investigation, not a confirmed
explanation of the buildd failure:
https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_cond_wait.html
The function is unchanged in upstream 20260926, but I have not tested that
release on Hurd and cannot infer its runtime result from this comparison.
This report is based on the public native build logs and source inspection.
I do not currently have a local Hurd test environment and have not reproduced
the failure locally. No validated fix is available yet. Help with reproducing
the failure and narrowing down the cause would be welcome.
Best regards,
Federico Molara
<federico@molara.net>