ghc-debug is a tool for performing precise memory analysis of Haskell programs. It relies on instrumenting Haskell programs with a server that answers queries about the process’s heap to a ghc-debug client over a unix socket. The client process can also take a snapshot of the debuggee process’s memory for offline analysis.

However, it is not necessary to link in a server process to be able to read and interpret the heap of a Haskell program. Connecting to a process via a debugger such as the GNU Debugger (GDB) allows you to read the various data-structures that comprise the Haskell heap provided you have debugging symbols to locate and identify various Haskell Runtime System data-structures.

We describe how uninstrumented Haskell processes can be analysed by connecting to them via GDB and mimicking a traditional ghc-debug server by using the GDB API to serve bits of the process’s memory in a ghc-debug compatible format. This also allows you to perform ELF coredumps of running Haskell process’s and serve their heap offline for analysis using the usual suite of ghc-debug clients and tools.

This method of analysis offers various advantages for analysing and debugging the heap of production systems, avoiding the need to expose a ghc-debug server that drastically increases the surface area for vulnerabilities and is generally unsuitable to run in production environments. Instead, a coredump of the process can be taken using standard utilities such as the gcore command from the GDB suite, and then analysed offline while leaving the original process untouched. It is also much faster and simpler to take an ELF coredump of a process as compared to ghc-debug snapshots which are collected through a complex traversal of the Haskell heap. Furthermore, it can also be useful to debug crashed processes and reconstruct the state of the heap just prior to the crash.