https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63564
--- Comment #4 from Kostya Serebryany <kcc at gcc dot gnu.org> --- (In reply to Bernd Edlinger from comment #3) > In the original example (it was ported from windows, > and the windows semaphores are completely immune > against this kind of error) the sem_post were in > *another* thread and there were several milliseconds > between the free the next malloc. So this is > already a really, really hard to find bug. > But what I don't understand, why the malloc does > *not* crash when address sanitizer is used. If the program has undefined behavior then the program's behavior is, well, undefined. You can not expect malloc to crash if there is a bug in the code. asan's malloc does not rely on malloc headers for bookeeping so it did not crash. > The same for thread sanitizer, it does not spot > the error, and the error does not happen in debug > builds only in release builds. Good point. tsan does intercept sem_post/sem_wait but does not detect when there is a use-after-free on it (we do it for pthread_mutex_lock though). Dmitry, You may want to add that to tsan.
