How to get stack traces out of GHC executables?

Learn
1

I’m trying to get stack traces from a live running GHC (version 9.2.2) compiled Haskell program.

I understand I need to send SIGQUIT to the process to get the stacktraces of the currently running threads.

But everytime I do this I just get the message: “This build does not support backtraces.”

This is what I have done:

  1. Our build is using nix, so I’ve added the following to the overrides for the GHC build:
ghc = 
  old.ghc.overrideAttrs (oldAttrs: {
    configureFlags = oldAttrs.configureFlags ++ ["--enable-dwarf-unwind"];
    buildInputs = oldAttrs.buildInputs ++ [pkgs.elfutils];
  });
  1. I’ve added the following flags to all the builds of our packages:
-ticky
-g
-fprof-auto
-fprof-auto-calls
  1. I added the flag --enable-debug-info to the cabal build command.

I don’t know what else to do. The docs say:

On POSIX-compatible platforms GHC’s runtime system (when built with libdw support) will produce a stack trace on stderr when a SIGQUIT signal is received

It doesn’t say here how to build with libdw support, but I read somewhere elsewhere that one needed to add --enable-dwarf-unwind, and indeed when I did that the GHC build initially complained about not being about to find the libdw library until I added elfutils to the buildInputs.

The error message also doesn’t make it clear whether the build of GHC doesn’t support backtraces or the build of my executable doesn’t support backtraces. Which makes hunting this down even more difficult.

What am I missing? Is there anyway to ask GHC whether it’s compiled with libdw support so I can at least work out whether the problem is with the GHC build or the build of my executable?

2

Note: GHC 9.2.2 is an older version (my OS lists GHC 9.4.7 as the default version it would install; using GHCup directly would provide even more recent releases).

Alright, nothing useful appears when I search for:

ghc haskell stack trace sigquit sigquit This build does not support backtraces

In this situation, your best option is to try making a MRE (minimum reproducible example) from the failing program’s codebase:

  • as you do, you could realise there was a detail that was missed in the original build process for that program;

  • if not, you can then present the (reliably-failing) MRE as part of a bug report.