Test fails on GNU Hurd
PeterBBBBB opened this issue · 8 comments
Builds OK on Hurd, but dumatest fails to run. Looks like it hits an exit(-1) somewhere, but there is no useful error message
build.log
Full log here
https://buildd.debian.org/status/fetch.php?pkg=duma&arch=hurd-i386&ver=2.5.21-2&stamp=1633376424&raw=0
Thanks for the report. I've recently added Hurd support to another project using Debian GNU/Hurd — mostly a positive experience.
I was using the 2021 Debian snapshot release in a KVM, and regularly updated it, which was successful for a month or two. Unfortunately, something happened and it failed to reboot. A quick examination revealed the filesystem was heavily corrupted, and after a full fsck, many files were filled with NULL bytes.
I'll set it up again soon, and this time around take regular snapshots. I'm not sure what would be happening here, but I'll let you know once I've been able to take a look.
I think this might be a problem with fprintf on Hurd,
which would explain why there is no error message.
Googling Hurd & fprintf gives several examples....
I’ve done some investigation, running up Hurd in a KVM.
All the test programs fail (Console just shows ‘Killed’) except for thread-test which runs just fine.
I attach a backtrace for dumatest.
It looks like it goes into an infinite loop, repeating every 10 lines in the trace.
Probably blows the stack.
Hope this helps,
Peter
Getting the top of the stack would allow to get the root cause of the assertion failure.
The infinite loop happens just because printf uses allocation, which triggers an assertion again, etc.
Hopefully a more useful backtrace
Getting the top of the stack would allow to get the root cause of the assertion failure.
The infinite loop happens just because printf uses allocation, which triggers an assertion again, etc.
Thanks for looking into this - I haven't yet had time to configure a good Hurd testing environment.
There are two ways to handle this case.
You could use a non-allocating printf function - we're doing this in some other projects that prints backtraces (and also uses DUMA) even in the case of OOM - for example see https://gitlab.com/dps8m/dps8m/-/tree/master/src/dpsprintf based on yasprintf. This really increases the size and complexity and amount of code in DUMA, so I likely won't go this route.
For the second option, might you be able to see if the failure still happens when you set one or both of DUMA_DISABLE_BANNER and DUMA_OUTPUT_FILE in the environment?
The DUMA defines did not seem to make a difference, but I have again with Samuel's libc 2.33-9 and tests now work if DUMA_DISABLE_BANNER is set. Not tried DUMA_OUTPUT_FILE again yet.
Issue also discussed here
(https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1016106)
We have a fix now, in Hurd's libc.
Closing here.