summaryrefslogtreecommitdiff
path: root/ghc.mk
diff options
context:
space:
mode:
authorSimon Marlow <marlowsd@gmail.com>2010-08-24 11:35:37 +0000
committerSimon Marlow <marlowsd@gmail.com>2010-08-24 11:35:37 +0000
commitea0bfdada955e3f5de8c38b06c831f6dc64ba0f2 (patch)
tree32a5db7c029d78da1d238407bfa3537ac2b54c00 /ghc.mk
parentda6d48859824bfcf5339a233412fd704bc75ad18 (diff)
downloadhaskell-ea0bfdada955e3f5de8c38b06c831f6dc64ba0f2.tar.gz
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.
Diffstat (limited to 'ghc.mk')
0 files changed, 0 insertions, 0 deletions