|
From: <led...@vt...> - 2007-10-26 14:38:30
|
I have noticed that valgrind often warns you about use of uninitialized memory only when it is used in a branch or conditional. Unfortunately, this means that sometimes the original UMR is far away from where the error happens. For example: I have an array of N complex values. I perform an operation that produces N-1 complex values (an FM demodulation). I then perform a magnitude squared operation and mistakenly use N values instead of N-1. Here the Nth input to the mag square is uninitialized. I then perform an FFT, find a peak in the fft, calculate a value from the peak, do some more calculations that mix in other measurements, and finally get a metric that is used an if statement. At this point, valgrind finally warns me that I'm doing something based on uninitialized memory. However, if that uninitialized memory happened to be a NaN, all my subsequent values are hosed. The group of developers I work with is starting to adopt valgrind as part of our code reviewing process, but several developers have complained of valgrind issuing errors much later in the code than they actually happen. I have discussed this issue with another developer, and he suggested that this behavior is by design; that UMRs happen all the time under the hood, that real errors are hard to distinguish from reads from alignment memory, and that valgrind is only flagging UMRs in branches because it can't otherwise determine if a UMR is an actual error. I would argue that any arithmetical operation performed on uninitialized memory should result in an error. I understand that flagging any read from uninitialized memory will result in a slew of false alarms, but I can't see any situation in which the use of uninitialized memory in an arithmetic instruction would produced desirable deterministic results. At least I think valgrind could tell the developer where the first read of uninitialized memory occurred so the developer doesn't have to spend time tracing back through code to determine through code inspection something that valgrind has been keeping track of all along. Just a suggestion, Cass Dalton |