Admin message

Due to a large amount of spam we do not allow new users to create repositories, they are "external" users. If you are a new user and want to create a repository, for example for forking GHC, open a new issue on ghc/ghc using the "get-verified" issue template

Segfault in HLS testsuite with ghc 9.10.3 due to (b9f49013061efcb2ae1d0986fdad3baf39994067)
## Summary @wz1000 and me traced back a segfault in HLS starting with 9.10.3 to commit b9f49013061efcb2ae1d0986fdad3baf39994067. We should revert/Fix "rts/linker/PEi386: Don't repeatedly load DLLs" (b9f49013061efcb2ae1d0986fdad3baf39994067) It's unclear the exact reason why it happens at this point but it seems the strings that should refer to dlls get corrupted and end up pointing to garbage instead. This is dependent on GC timings. Running the tests with a sufficiently large nursers avoids the crashes. My theory at this point is that we store the address and some kind of `ByteArray` and only pass the pointer to the RTS. With things going havoc down the line when the haskell array get's gced. But we are still actively investigating this. The issue seems to be that the HLS testsuite driver loads multiple files involving TH. To do so it loads various libraries. Eventually it segfaults during loading one of those libraries with a backtrace like: ``` #0 0x00007ffee0f25896 in wcscmp () from C:\WINDOWS\System32\ucrtbase.dll #1 0x00007ff6e5eadbaf in compare_path (key1=140690156649928, key2=140690141339840) at rts\linker/PEi386.c:556 #2 0x00007ff6e5e997d8 in lookupHashTable_inlined (table=<optimized out>, key=140690141339840, f=<optimized out>, cmp=0x7ff6e5eadb90 <compare_path>) at rts/Hash.c:226 #3 lookupHashTable_ (table=<optimized out>, key=140690141339840, f=<optimized out>, cmp=0x7ff6e5eadb90 <compare_path>) at rts/Hash.c:238 #4 0x00007ff6e5ea7510 in isDllLoaded (cache=0x7ff6ecb365a0, dll_name=0x7ff4f9e5e0c0 L"C:\\WINDOWS\\system32\\wsock32") at rts\linker/PEi386.c:566 #5 0x00007ff6e5ea72d6 in addDLL_PEi386 (dll_name=0x7ff4f9e5e0c0 L"C:\\WINDOWS\\system32\\wsock32", loaded=0x368dc38) at rts\linker/PEi386.c:945 #6 0x00007ff6e5865dd1 in loadNativeObj (path=0x7ff4f9e5e0c0 L"C:\\WINDOWS\\system32\\wsock32", errmsg=0x7ff4f9e5e108) at rts/Linker.c:1841 #7 0x00007ff6e7e0a1b0 in hs_atomicwrite64 () #8 0x0000000000000000 in ?? () ``` The hs_atomic in the backtrace is confusing, but I'm not sure it's relevant. ## Steps to reproduce TODO ## Expected behavior No segfaults. ## Environment * GHC version used: Optional: * Operating System: * System Architecture:
issue