Fault-localization is an important element in software debugging. Establishing the chain of events that led to the failure is an effective way to investigate and fix bugs. However, error reporting focuses on error values being \emph{produced}, whereas it is often the case that faults stems from the data being \emph{consumed} being wrong.

As an example, using head on an empty list will give us a stack trace indicating where the call to head was located. However, a crash involving head is usually due to the list being evaluated being unexpectedly empty.

In non-lazy languages, the origin of the consumed data can be hard to realize, requiring sophisticated data-flow analysis. In lazy languages however, data being consumed is often unevaluated until right before the error! By extending GHC’s Haskell Program Coverage with CSI: Haskell, we can trace recently evaluated locations and establish where the data being consumed originates. Integrating tracing into GHC itself allows us to improve runtime error messages by including a summary of recently evaluated locations in the message itself and give a hint as to what was happening immediately prior to the error.

With additional post-processing (added to GHCs Trace library), users can take generated trace and build graph and graph visualizations to help understand what was happening at the time of the crash. This lets us establish the chain of events and locate the origin of the fault, making our programs easier to debug.

In this talk I will describe the design and implementation of CSI: Haskell, give a demo on how it works, and talk about future work on improving the visualization and summarization of the traces, and how we could improve error messages even further.

Matthías Páll Gissurarson is a PhD student at Chalmers University of Technology. His interests include functional programming, typed-holes, program synthesis, compilers, security, and repair.