GitLab

Joseph Jezak reported darcs-2.4.4 SIGSEGV in interactive mode in ghc-6.12.3.
So I've concluded ppc also has rotten native adjustor. I don't have hardware
to verify the patch (ticket #3516 should help to test it), but I think it will
help (as similar patch helped for ia64 and ppc64).

I'm not sure if this could lead to a crash or not, but it upsets +RTS -DS
Might be related to #4265

Stops user-installed packages breaking the build

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.