Even if the modified program fails to crash and fails to trigger the anomaly detector, there's no way to prove that the program still works as intended. For example, suppose the fix of an overflow also elides the initialization of some other variable, which results in data corruption? How is that better than an overflow/crash?

The approach is valuable even if you can't prove the program still works as intended (which is impossible in general). The goal is to have a program that works a bit better than it would without ClearView.

For example, the unmodified web server may have a buffer overflow that can lead to the system being hijacked. ClearView modifies the program so that a connection is prematurely dropped, but hijacking is prevented. Neither behavior was what was the programmer intended, but we've taken a serious bug and replaced it with a minor bug. That's valuable.

The real issue is whether the modifications do in fact make the program work a bit better. Rinard's experiments indicate that they do, at least for the applications used in the experiments.

My company makes a code understanding tool called CodeSurfer. It's not open source, and it's not free (though it is free for academic use).

You can browse your code, following dependences and definitions. You can also construct queries, do isolate what statements can affect a particular variable, and a bunch of other tricks based on static analysis. There's a programming interface too.

Other good ways to get your head around code (speaking as a software engineer, rather than a guy promoting his company):

• I agree with whoever suggested breaking in a random spot and stepping through the code.
  
• Talk to the other developers, if they are around. Don't suffer in silence for the sake of doing it on your own.
  
• Pick a minor throwaway feature (eg every button should be blue) and modify the code to add that feature. This forces you really learn the code, but without the pressure of making a real product-worthy feature.