https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125781
--- Comment #1 from Mike Crowe <mac at mcrowe dot com> --- This problem affects the std::condition_variable_any wait overloads that take a stop token too because their implementation creates a stop_callback on the stack. futex(futex_op_wake_private) is being called to wake up any threads that might be blocked on the semaphore. If the semaphore has gone out of scope then there can't be any waiters that need waking up so the call is unnecessary. I think that the futex(futex_op_wake_private) call with an invalid address will do one of three things inside the kernel: 1. It will discover that no-one is waiting on the address and just return. (I think that this is by far the most likely outcome.) 2. It will discover that the address is no longer mapped into the process and return -EFAULT, but __platform_notify() doesn't check the return value so this doesn't matter. 3. It will discover that the address has been re-used by something else that has called futex(wait) on it, and that caller will be spuriously woken up. Spurious wakeups are permitted. IMO none of these things are bad and none of this code appears to be used on platforms that lack futex(). I think that whilst this is a theoretical problem and Valgrind is right to complain about it, it has no real-world consequences. If the implementors agree with this analysis then we just need to work out how to teach Valgrind to ignore it.
