search

johnsonjh / duma

duma: Detect Unintended Memory Access (D.U.M.A.) - A Red-Zone memory allocator
https://github.com/johnsonjh/duma
GNU General Public License v2.0
101 stars 10 forks source link

Test fails on GNU Hurd #172

Closed PeterBBBBB closed 2 years ago

PeterBBBBB commented 3 years ago

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

johnsonjh commented 3 years ago

@PeterBBBBB

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.

PeterBBBBB commented 2 years ago

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....

PeterBBBBB commented 2 years ago

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

gdb.txt

sthibaul commented 2 years ago

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.

PeterBBBBB commented 2 years ago

Hopefully a more useful backtrace

gdb.txt

johnsonjh commented 2 years ago

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?

PeterBBBBB commented 2 years ago

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)

PeterBBBBB commented 2 years ago

We have a fix now, in Hurd's libc. Closing here.