#16150: Data races in itimer_thread_func reported by ThreadSanitizer -------------------------------------+------------------------------------- Reporter: gnezdo | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 8.4.4 Resolution: | Keywords: Operating System: Linux | Architecture: x86_64 Type of failure: Incorrect result | (amd64) at runtime | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by Phyx-): I believe #16147 is similar @bgamari, In that case there are multiple OS threads even on the non-threaded runtime. But the `ACQUIRE_LOCK` and `RELEASE_LOCK` macros expand to nothing on the non-threaded runtime, which introduces a race condition with shutdown of the loop and rts. Which is why I think it happens on the non-threaded but not the threaded. See https://ghc.haskell.org/trac/ghc/attachment/ticket/16147/sample.txt I think in this case we always want a lock, so `ACQUIRE_LOCK` and `RELEASE_LOCK` should be changed to `OS_ACQUIRE_LOCK` to `OS_RELEASE_LOCK`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/16150#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler