Duck! Another blag incoming!

Memcheck history


I am sitting the valgrind room. Because I kinda heard everything in the python room. Talk by Julian Seward.

What is memcheck?

Process-level virtual machine, that instruments C-code to checks for memory problems.

  • Use of uninitialized memory
  • Reading/writing memory after it has been free'd
  • Reading/writing off the end of malloc'd blocks
  • Memory leaks



  • Initial desing

2001 -2004

  • Redesign
  • Early Key-Developer
  • Port to x86_64


  • memcheck has to scale. Must run OpenOffice, Firefox
  • Zero false positives
  • Be easy to use, "-g -O" and go
  • To have influence: fix code in the world


  • Build the worst thing that actually works
  • Assertions are always on (good idea?)
  • Problem: They could not interact with pthreads will, because if crappy glibc [1]
  • Four bytes to track all the memory
  • Sequentialize threads
  • Copy-annotate or disassemble-resynthesizes? -> disassemble-resynthesizes
  • Use it in CI


  • Ports were difficult (OSX, AIX) -> a lot of undocumented interactions


  • Didn't complain much about slowness
  • Didn't believe what it is telling them
  • Today totally accepted

Correct programs -> memcheck can still complain

  • Access below stack-pointer
  • Comparison with partial defined words


IR Design

ASM -> IR -> Instrumented IR -> ASM


  • Compiler optimisations if (A && B) => if (B && A)
  • 64 bit shadow memory
  • Threading

Expected but not a problem

  • Kernel interface changes
  • Autovectorization

GO Rust!

[1]Crappy: my words. The do shared objects, but they are so interconnected, that they are useless.

This entry was tagged as valgrind fosdem