[GHC] #3618: memory-leak detector in +RTS -DS fails to track allocations in constructors

[GHC]

#3618: memory-leak detector in +RTS -DS fails to track allocations in constructors
---------------------------+------------------------------------------------
  Reporter:  guest         |           Type:  bug           
    Status:  new           |       Priority:  normal        
 Milestone:  _|_           |      Component:  Runtime System
   Version:  6.12.1 RC1    |       Keywords:                
  Testcase:                |      Blockedby:                
Difficulty:  Unknown       |             Os:  Linux         
  Blocking:                |   Architecture:  x86_64 (amd64)
   Failure:  None/Unknown  |  
---------------------------+------------------------------------------------
Changes (by simonmar):

  * failure:  => None/Unknown


Comment:

 I got rid of the memory leak detector in the RTS recently:

 {{{
 Tue Aug 24 12:35:37 BST 2010  Simon Marlow <marlowsd at gmail.com>
   * Remove the debugging memory allocator - valgrind does a better job

   I got fed up with the constant bogus output from the debugging memory
   allocator in RtsUtils.c.  One problem is that we allocate memory in
   constructors that then isn't tracked, because the debugging allocator
   hasn't been initialised yet.

   The bigger problem is that for a given piece of leaking memory it's
   impossible to find out where it was allocated; however Valgrind gives
   output like this:

   ==6967== 8 bytes in 1 blocks are still reachable in loss record 1 of 7
   ==6967==    at 0x4C284A8: malloc (vg_replace_malloc.c:236)
   ==6967==    by 0x4C28522: realloc (vg_replace_malloc.c:525)
   ==6967==    by 0x6745E9: stgReallocBytes (RtsUtils.c:213)
   ==6967==    by 0x68D812: setHeapAlloced (MBlock.c:91)
   ==6967==    by 0x68D8E2: markHeapAlloced (MBlock.c:116)
   ==6967==    by 0x68DB56: getMBlocks (MBlock.c:240)
   ==6967==    by 0x684F55: alloc_mega_group (BlockAlloc.c:305)
   ==6967==    by 0x6850C8: allocGroup (BlockAlloc.c:358)
   ==6967==    by 0x69484F: allocNursery (Storage.c:390)
   ==6967==    by 0x694ABD: allocNurseries (Storage.c:436)
   ==6967==    by 0x6944F2: initStorage (Storage.c:217)
   ==6967==    by 0x673E3C: hs_init (RtsStartup.c:160)

   which tells us exactly what the leaking bit of memory is.  So I don't
   think we need our own debugging allocator.

     M ./rts/RtsStartup.c -11
     M ./rts/RtsUtils.c -146
 }}}

 I also added a section on debugging memory leaks to the wiki:
 [wiki:Debugging/RuntimeSystem].

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/3618#comment:5>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler