In the long run, it may be more efficient to use the clang "sanitizer" suite instead of Valgrind. It will need two runs (ASan+LSan+UBSan and MSan) but the total run time should be lower.
http://clang.llvm.org/docs/UsersManual.html#controlling-code-generation > Valgrind can find the following kinds of problems. > > 1. Accessing memory you shouldn't, e.g. overrunning and underrunning heap > blocks, overrunning the top of the stack, and accessing memory after it has > been freed. ASan checks for these, plus a few cases that Valgrind doesn't catch. Since ASan has heavy compiler support, it can place redzones around globals and stack variables. > 2. Using undefined values, i.e. values that have not been initialised, or that > have been derived from other undefined values. MSan will check for these, but I don't think it's ready to be used on Firefox. > 3. Incorrect freeing of heap memory, such as double-freeing heap blocks, > freeing non-heap blocks, or mismatched use of malloc/new/new[] versus > free/delete/delete[]. ASan checks for these. (The last one is controlled by alloc_dealloc_mismatch and is off by default on Mac.) > 4. Overlapping src and dst pointers in memcpy and related functions. ASan checks for these too. (Except on Mac, because on 10.9, memcpy and memmove share an implementation: http://llvm.org/bugs/show_bug.cgi?id=16362 and https://code.google.com/p/address-sanitizer/issues/detail?id=226) > 5. Memory leaks. LSan can check for these, and it's cheap to turn on LSan and ASan at the same time. (LSan uses a reachability heuristic similar to Valgrind's --show-leak-kinds=definite) _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
