Hi, I was going to report this bug on GitLab as wiki suggests, but this requires my account to be manually approved, so I'm going to write it down here. (But if you can approve "matshch" on GitLab I will appreciate it.) Consider the next program: import GHC.Conc main = setNumCapabilities 257 Compiling it with recent GHC and running it causes segmentation faults sometimes, depending on the compiler version and the environment. Here is the setup that works for me every time: $ printf "import GHC.Conc\nmain = setNumCapabilities 257" | docker run -i --rm haskell:9.10.1-bullseye runghc; echo $? 139 I first discovered this issue in Nix builds, and the next setup also crashes every time for me (it uses GHC 9.6.6 under the hood): $ nix run nixpkgs/b681065d0919f7eb5309a93cea2cfa84dec9aa88#ghc -- -threaded conc.hs; ./conc [1] 311106 segmentation fault (core dumped) ./conc For this fail I have a stack trace that is showing that crash happens somewhere in RTS: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x000000000049d34f in assignNurseriesToCapabilities () [Current thread is 1 (LWP 311106)] (gdb) bt #0 0x000000000049d34f in assignNurseriesToCapabilities () #1 0x000000000049d96c in storageAddCapabilities () #2 0x000000000047eaea in setNumCapabilities () #3 0x000000000041042d in base_GHCziConcziSync_setNumCapabilities1_info () #4 0x0000000000000000 in ?? () I have tried reproducing it with GHCup versions of GHC and have found that it requires more capabilities to cause a crash. If you bump the setNumCapabilities argument to 259, it causes the program to crash under both ghc and runghc of versions 9.6.6, 9.8.4 and 9.10.1. I have also encountered cases (with 258 capabilities IIRC) when it crashes not on every program launch, and also noticed that ghci and runghc looks more susceptible to the problem. I first discovered this issue while upgrading our platform to NixOS 24.11, builds were failing on hedgehog tests. As I have discovered, it was seeing that our build machine has 256 cores, planning to run 256 workers, so it set capabilities to number of cores + 2 (so 258 in our case) to make some room for IO threads, and was crashing as I have shown above. -- Artem Leshchev