Opened 11 years ago

Last modified 4 years ago

#881 new feature request

Improve space profiling for references

Reported by: simonpj Owned by:
Priority: normal Milestone:
Component: Profiling Version: 6.4.2
Keywords: Cc: pho@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


GHC's great space profiling tools don't appear to be much help when your leaked memory is stored in references (IORefs, StablePtrs, etc). I had a real-life case where the allocation profile showed me where the leaked data came from, and I could guess that it was being held by some reference, but I couldn't tell which one. Retainer set profiling showed a big suspicious entry for "SYSTEM", but I couldn't find any way to pinpoint the problem. (It ended up being a missing freeStablePtr in hsgnutls, found by code inspection.)

Here's a contrived example that just allocates a bunch of IORefs:

    import Control.Monad
    import Data.IORef

    main = repeatM (newIORef [1,2,3])
    repeatM io = liftM2 (:) io (repeatM io)

Retainer set profiling shows everything in "SYSTEM". None of the other profiling methods say anything interesting either. What I'd like to get, I think, is (1) your memory is being held in IORefs (2) allocated by this cost center and (3) being retained by this cost center. I guess I'm looking for something like a memory profiler for a traditional language.

Andrew Pimlott

Simon Marlow comments: "The relevant predicate "is retainer" is pretty much built into the retainer profiler, and it returns true only for thunks if I recall correctly. Being able to tweak this, or maybe just install a better default would be an improvement.

Change History (9)

comment:1 Changed 10 years ago by igloo

Milestone: 6.8

comment:2 Changed 9 years ago by simonmar

Milestone: 6.8 branch_|_

No immediate plans to do anything about this.

comment:3 Changed 9 years ago by SamB

Isn't the problem here that the retainer profiling is stopping at the IORef and writing the memory off as retained by "SYSTEM", when it should go back and find out who retains the IORef?

comment:4 Changed 8 years ago by simonmar

Architecture: UnknownUnknown/Multiple

comment:5 Changed 8 years ago by simonmar

Operating System: UnknownUnknown/Multiple

comment:6 Changed 7 years ago by PHO

Cc: pho@… added

comment:7 Changed 4 years ago by morabbin

Type of failure: None/Unknown

Orphaned feature request?

comment:8 Changed 4 years ago by simonmar

I think this might be fixed, since MUT_VAR is considered a retainer, but it needs testing (don't have prof libs installed on my laptop and I'm on slow wifi right now).

comment:9 Changed 4 years ago by simonmar

The example still reports "SYSTEM", but I don't see an obvious reason why, so not closing this ticket.

Updated code:

{-# OPTIONS_GHC -fprof-auto #-}
import Control.Monad
import Data.IORef
import System.Environment

main = do
  [n] <- getArgs
  replicateM (read n) (newIORef [1,2,3])
$ ./881 10000000 +RTS -hr -K1g -S 
Note: See TracTickets for help on using tickets.