- 03 Sep, 2010 1 commit
-
-
Simon Marlow authored
-
- 27 Aug, 2010 1 commit
-
-
Simon Marlow authored
I'm not sure if this could lead to a crash or not, but it upsets +RTS -DS Might be related to #4265
-
- 02 Sep, 2010 2 commits
-
-
Ian Lynagh authored
Stops user-installed packages breaking the build
-
Ian Lynagh authored
-
- 31 Aug, 2010 1 commit
-
-
benl@ouroborus.net authored
-
- 30 Aug, 2010 10 commits
-
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
benl@ouroborus.net authored
-
- 27 May, 2010 1 commit
-
-
benl@ouroborus.net authored
-
- 28 Aug, 2010 2 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 27 Aug, 2010 4 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
Ian Lynagh authored
-
- 26 Aug, 2010 1 commit
-
-
Ian Lynagh authored
-
- 24 Aug, 2010 1 commit
-
-
Ian Lynagh authored
-
- 26 Aug, 2010 2 commits
-
-
Simon Marlow authored
-
Simon Marlow authored
-
- 24 Aug, 2010 2 commits
-
-
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.
-
Simon Marlow authored
-
- 25 Aug, 2010 2 commits
-
-
simonpj@microsoft.com authored
-
simonpj@microsoft.com authored
-
- 24 Aug, 2010 3 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
Hack: dblatex normalises the name of the main input file using os.path.realpath, which means that if we're in a linked build tree, it find the real source files rather than the symlinks in our link tree. This is fine for the static sources, but it means it can't find the generated sources. We therefore also generate the main input file, so that it really is in the link tree, and thus dblatex can find everything.
-
Ian Lynagh authored
-
- 23 Aug, 2010 3 commits
-
-
simonpj@microsoft.com authored
It's not just when cleaning!
-
simonpj@microsoft.com authored
Because rtsIsProfiled is only available in stage2
-
Simon Marlow authored
This was leading to looping and excessive allocation, when the computation should have just blocked on the black hole. Reported by Christian Höner zu Siederdissen <choener@tbi.univie.ac.at> on glasgow-haskell-users.
-
- 18 Jul, 2010 1 commit
-
-
marcotmarcot authored
The checkHeap function assumed the allocated part of the block contained only alive objects and slops. This was not true for blocks that are collected using mark sweep. The code in this patch skip the test for this kind of blocks.
-
- 22 Aug, 2010 3 commits
-
-
Ian Lynagh authored
-
Ian Lynagh authored
This pulls from the upstream repos, for those packages which have upstreams
-
Ian Lynagh authored
Stops the docs going out of sync with the code.
-