## Summary A program built with GHC 9.14.1 is crashing, when it was not with GHC 9.12.3. ``` internal error: END_TSO_QUEUE object (0x7fc78a1facd8) entered! Stack trace: model-lib.test.NonSmallCellLungCancer: Failed to get stack frames of current process: No DWARF information found: Success 0x7fc78a17e290 set_initial_registers (/nix/store/7c1a2k4z6zmasv5wcl5kdkdvnz2qwv86-ghc-9.14.1/lib/ghc-9.14.1/lib/x86_64-linux-ghc-9.14.1-bf25/libHSrts-1.0.3_thr-ghc9.14.1.so) 0x7fc7879becd0 dwfl_thread_getframes (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so) 0x7fc7879be6eb get_one_thread_cb (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so) 0x7fc7879bead4 dwfl_getthreads (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so) 0x7fc7879bf042 dwfl_getthread_frames (/nix/store/1nqqjacc6dnj61jlpgz5hk9zdjbfidbr-elfutils-0.194/lib/libdw-0.194.so) 0x7fc78a17e9f7 libdwGetBacktrace (/nix/store/7c1a2k4z6zmasv5wcl5kdkdvnz2qwv86-ghc-9.14.1/lib/ghc-9.14.1/lib/x86_64-linux-ghc-9.14.1-bf25/libHSrts-1.0.3_thr-ghc9.14.1.so) 0x7fc78a188197 rtsFatalInternalErrorFn (/nix/store/7c1a2k4z6zmasv5wcl5kdkdvnz2qwv86-ghc-9.14.1/lib/ghc-9.14.1/lib/x86_64-linux-ghc-9.14.1-bf25/libHSrts-1.0.3_thr-ghc9.14.1.so) 0x7fc78a1883ef barf (/nix/store/7c1a2k4z6zmasv5wcl5kdkdvnz2qwv86-ghc-9.14.1/lib/ghc-9.14.1/lib/x86_64-linux-ghc-9.14.1-bf25/libHSrts-1.0.3_thr-ghc9.14.1.so) 0x7fc78a1cb37b stg_END_TSO_QUEUE_info (/nix/store/7c1a2k4z6zmasv5wcl5kdkdvnz2qwv86-ghc-9.14.1/lib/ghc-9.14.1/lib/x86_64-linux-ghc-9.14.1-bf25/libHSrts-1.0.3_thr-ghc9.14.1.so) (GHC version 9.14.1 for x86_64_unknown_linux) Please report this as a GHC bug: https://www.haskell.org/ghc/reportabug ``` This is unfortunatelly not reproducible (this program sometimes hang or sometimes finish without any issue). And the program is part of a large proprietary codebase, so I don't know what to do. ## Steps to reproduce I don't have a simple repro that I can share unfortunately. If you have some suggestion of operation I can launch to better understand the problem, please tell me, I'll do it. Note that it is completly possible that the bug is on our side (we are doing a lot of FFI call to C code and JIT compilation), so maybe somethnig was wrong before and the switch to GHC 9.14 just made it obvious. But I had never saw such failure before. ## Expected behavior What do you expect the reproducer described above to do? ## Environment * GHC version used: 9.14.1 Optional: * Operating System: Linux * System Architecture: x86-64