Changes between Version 2 and Version 3 of Debugging/RuntimeSystem


Ignore:
Timestamp:
Aug 24, 2010 11:47:28 AM (4 years ago)
Author:
simonmar
Comment:

add info about debugging leaks

Legend:

Unmodified
Added
Removed
Modified
  • Debugging/RuntimeSystem

    v2 v3  
    3131}}} 
    3232Of these, `-DS` (sanity checking) is special. It switches on a rather expensive heap-consistency check which runs after every garbage collection.  Your program will run a lot slower, but it helps when tracking down garbage-collection errors. 
     33 
     34== Debugging memory leaks == 
     35 
     36There are three kinds of memory leaks: 
     37 
     38=== The GC is retaining something when you think it shouldn't === 
     39 
     40This doesn't come up very often, to be honest.  If it happens then you need to trace back through the object graph to find the path that lead to the offending object being retained by the GC.  This is quite tedious to do using gdb, but I don't know of a better way.  See [wiki:Debugging/CompiledCode]. 
     41 
     42=== Some malloc'd memory has not been free'd === 
     43 
     44Fortunately this one is quite easy.  Compile the program with `-debug`, and run it under [http://valgrind.org/ Valgrind], with the options `--leak-check=full --show-reachable=yes`, to get a full report on leaking memory and where it was allocated from.  Some leaks are expected: for example, we don't release the heap data structures during shutdown of a standalone program, because there might be outstanding foreign calls referring to data in the heap. 
     45 
     46=== Some blocks allocated from the block allocator have not been freed === 
     47 
     48The debugging RTS checks for these leaks itself, and complains very loudly if it finds any.  Just compile the program with `-debug` and run it.  The code to check for leaks is in [[GhcFile(rts/sm/Sanity.c)]], `memInventory`. 
     49 
     50 
     51 
     52 
     53