Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[gdb/build] Workaround tsan select bug
When building gdb with -O0 and -fsanitize-thread, I run into a large number of timeouts caused by gdb hanging, for instance: ... (gdb) continue^M Continuing.^M [Inferior 1 (process 378) exited normally]^M FAIL: gdb.multi/stop-all-on-exit.exp: continue until exit (timeout) ... What happens is the following: - two inferiors are added, stopped at main - inferior 1 is setup to exit after 1 second - inferior 2 is setup to exit after 10 seconds - the continue command is issued - because of set schedule-multiple on, both inferiors continue - the first inferior exits - gdb sends a SIGSTOP to the second inferior - the second inferior receives the SIGSTOP, and raises a SIGCHILD - gdb calls select, and blocks - the signal arrives, and interrupts select - ThreadSanitizers signal handler is called, which marks the signal pending internally - select returns -1 with errno == EINTR - gdb calls select again, and blocks - gdb hangs, waiting for gdb's sigchild_handler to be called This is a bug [1] in ThreadSanitizer. When select is called with timeout == nullptr, it is blocking but ThreadSanitizer doesn't consider it so, and consequently doesn't see the need to call sigchild_handler. Work around this by: - instead of using the blocking select variant, forcing a small timeout and - upon timeout calling a function that ThreadSanitizer does consider blocking: usleep, forcing sigchild_handler to be called. Tested on x86_64-linux. PR build/32295 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32295 [1] google/sanitizers#1813
- Loading branch information