1. 08 Sep, 2010 2 commits
  2. 07 Sep, 2010 1 commit
  3. 04 Sep, 2010 1 commit
  4. 29 Aug, 2010 1 commit
  5. 04 Sep, 2010 1 commit
  6. 03 Sep, 2010 3 commits
  7. 27 Aug, 2010 1 commit
  8. 02 Sep, 2010 2 commits
  9. 31 Aug, 2010 1 commit
  10. 30 Aug, 2010 10 commits
  11. 27 May, 2010 1 commit
  12. 28 Aug, 2010 2 commits
  13. 27 Aug, 2010 4 commits
  14. 26 Aug, 2010 1 commit
  15. 24 Aug, 2010 1 commit
  16. 26 Aug, 2010 2 commits
  17. 24 Aug, 2010 2 commits
    • 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
    • Simon Marlow's avatar
      da6d4885
  18. 25 Aug, 2010 2 commits
  19. 24 Aug, 2010 2 commits
    • Ian Lynagh's avatar
      89c56230
    • Ian Lynagh's avatar
      Change how the dblatex/lndir problem is worked around · 4e7bbe99
      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.
      4e7bbe99