Diagnose memory leaks on PINNED values with GHC 9.2.1 and up

I pride myself on my odd ability for diagnosing memory leaks on Haskell. I have sent some PRs on OSS with some neat diagrams to corroborate the fixes and they are always welcomed. It is a good way to get to know a project and can be considered a low level bug in most cases.

The common way to learn how to do this is reading the GHC user guide section on profiling and experimenting on your own programs. What I usually end up doing is this:

  1. Compile with profiling enabled: Either
    • ghc -prof -fprof-auto
    • stack build --profile
    • cabal v2-build --enable-profiling
  2. Generate some figures with ./program-exe +RTS -xc -L350 -p -hc
  3. Use hp2pretty to generate a diagram. This can involve pruning the uninteresting sections of the program-exe.hp file to get a specific interval in time.
  4. Identify the offending band on the resulting SVG, identify the cost centre stack reported on the .hp file and read the code.
  5. If a more specific cost centre is needed, I add a {-# SCC "slack0" #-} expr annotation at call sites that can be interesting. I repeat the previous points.

This is all fine and dandy! It works for most of the cases that you encounter.

But there was still a thorn on this approach: ByteStrings. On the Haskell heap these are PINNED objects. What this means is that the copying garbage collector gives them special treatment when moving values between the from space to the to space and lets them fixed in place. This is related to foreign pointers and the expectation of C-libraries of not having the values their pointers point moved without notice.

This manifests in diagrams with the following pattern:

Notice the purple band declared as PINNED without any cost-centre information. We would like to have information as in the band 96369, which when read from the .hp file gives us a series of cost-centres names separated by a /.

By the way, this is a real program. I was working on it a $JOB but had to throw my hands on the air as my usual bag of tricks did not work… on GHC 8.10.7.

That is right, my usual bag of tricks got more useful on GHC 9.2.1 as /geekosaur/ informed me #haskell @ libera. Now these PINNED values have normal cost-centres stack associated to them.

Sure, I had to update some dependencies to compile on the new GHC version. But once that was done I was left with a new binary that reported these figures:

Now I got info on the cost-centre stack 85488. I can search up until I get on a cost-centre for my program and force that value.

The leak ended up being a un-demanded selector function over parsed bytestring. The lack of inmediate demand meant that GHC had to leave those values around in case could be needed on the future. Easy to fix once you understand, a bang-pattern is what you need on those cases. This left me with the following diagram:

Win win win.

Conclusion

Now I feel more confident on my odd ability to diagnose memory leaks :-) . This would have taken me at least another afternoon to diagnose under GHC 8.10.7 . On GHC 9.2.3, it took me 15 min, great stuff.

Comentarios

Publicar un comentario

Entradas más populares de este blog

An apologia for lazy evaluation

An apologia of lazy evaluation As a programming language, laziness is the definitive feature of Haskell. Every other quality such as: higher order functions, Hindler-Milner type system or being lambda calculus based is present on other languages. In fact Haskell was born as a committee initiated language to avoid a proliferation of non-strict languages at the end of the 80's, putting all the effort before the same cart. If you take some time, and look at what HN , stack overflow or reddit has to say about the general sentiment of non Haskell programmer on laziness, it could be resumed on a single word: anxiety . It seems that space leaks due to laziness are unavoidable and that Haskell programmers choose to live with them. The methods of detecting them come from dynamic analysis of compiled programs . There is no general advice on how to avoid them apart from experience; an even then it not enough, as expert Haskell programmers still trip over them time to time. What hope do ...
Read more »

How to avoid correctness space leaks on a lazy setting in haskell

How to avoid space leaks on lazy setting How to avoid space leaks on lazy setting Table of Contents 1. A classification of space leaks 2. Avoiding strictness leaks 2.1. Repeatedly used functions over the same expressions 2.2. Using cost centres and one weird trick to catch them at run-time 3. Avoiding Liveness leaks 4. Avoiding excessive sharing leaks 4.1. Merge multiple passes over the data structure on a single pass 4.2. Move the creation of the generator inside the function and wrap it on a dumb function 4.3. Bite the bullet and use linear types 5. Conclusion Some posters on HN on made the observation that on my previous post I did not give general advice on how to avoid space leaks. This is specially important given that I ceded the point that exists a cluster (b) of space leaks that are of a correctness concern. The tools at our disposal come in two varieties: Defensive coding patterns Running program profiling I think the first ...
Read more »

Presenting data-forced, an alternative to bang patterns for long lived data structures

Presenting data-forced, an alternative to bang patterns for long lived data structures Table of Contents 1. The problem 2. The data-forced approach 3. UnliftedDatatypes have a different calling convention (CBV) 4. Conclusion As a consequence of my previous post , I crafted a new way to deal with liveness leaks : data-forced . It relies on CBV functions and tagging values when we know they have been evaluated. It is not complete, it is possible to be mis-used and not get any benefits, but it shows promise and gives stronger guarantees than the current status quo. Also, I am starting a new job next week, so I will have less time for hacking and writing. 1. The problem Long lived data structures that store thunks will keep the references needed to evaluate those thunks alive for a long time. This is a consequence of not pairing the denotation of the values with a good consumer. Current ways to deal with this on Haskell are: Use Bang patterns and/or se...
Read more »