mirror of
https://sourceware.org/git/glibc.git
synced 2024-12-24 03:31:07 +00:00
088136aa02
So I was able to reproduce the hangs in the original source, and debug it, and fix it. In doing so, I realized that we can't use anything complex to trigger the thread because that "anything" might also cause the expected segfault and force everything out of sync again. Here's what I ended up with, and it doesn't seem to hang where the original one hung quite often (in a tight while..end loop). The key changes are: 1. Calls to futex are error checked, with retries, to ensure that the futexes are actually doing what they're supposed to be doing. In the original code, nearly every futex call returned an error. 2. The main loop has checks for whether the thread ran or not, and "unlocks" the thread if it didn't (this is how the original source hangs). Note: the usleep() is not for timing purposes, but just to give the kernel an excuse to run the other thread at that time. The test will not hang without it, but is more likely to test the right bugfix if the usleep() is present. |
||
|---|---|---|
| .. | ||
| aarch64 | ||
| alpha | ||
| arc | ||
| arm | ||
| csky | ||
| generic | ||
| gnu | ||
| hppa | ||
| htl | ||
| hurd | ||
| i386 | ||
| ia64 | ||
| ieee754 | ||
| loongarch | ||
| m68k | ||
| mach | ||
| microblaze | ||
| mips | ||
| nios2 | ||
| nptl | ||
| or1k | ||
| posix | ||
| powerpc | ||
| pthread | ||
| riscv | ||
| s390 | ||
| sh | ||
| sparc | ||
| unix | ||
| wordsize-32 | ||
| wordsize-64 | ||
| x86 | ||
| x86_64 | ||