• Simon Marlow's avatar
    Remove the debugging memory allocator - valgrind does a better job · ea0bfdad
    Simon Marlow authored
    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.
    ea0bfdad
RtsStartup.c 11.8 KB