If the application reads from addressable memory that has not been written to since it was allocated, Dr. Memory reports an "uninitialized read" error. In order to avoid false positives, Dr. Memory does not report the use of uninitialized memory until something "meaningful" is done with that memory, such as a comparison or conditional branch or passing it to a system call. Variables or fields smaller than a word are often initialized without their containing word (variables and fields are typically word-aligned) being initialized. When these variables or fields are then copied, the uninitialized portion of each word is technically being read as an uninitialized value, but reporting such reads as errors would result in far too many errors.

When passing data structures to a system call, if the structure is initialized field-by-field then padding bytes may be left uninitialized. Dr. Memory will report errors on these as it does not know whether the kernel or a receipient on the other end might read it. To avoid these errors, memset the entire structure, or use a Dr. Memory error suppression (see Suppressing Errors) to ignore the error.

Here is an example of an uninitialized read error:

Error #2: UNINITIALIZED READ: reading 0xffbae108-0xffbae114 12 byte(s) within 0xffbae100-0xffbae114
Elapsed time = 0:00:00.214 in thread 19298
system call socketcall setsockopt args
    <system call>
0x08049a65 <my-socket-test+0x1a65> my-socket-test!main
    ??:0
0x0092dbb6 <libc.so.6+0x16bb6> libc.so.6<nosyms>!__libc_start_main
    ??:0
0x080489b1 <my-socket-test+0x9b1> my-socket-test!_start
    ??:0

When only part of a larger region is uninitialized, Dr. Memory reports the containing range to make it easier to track down the problem. This typically happens with buffers or structures passed to system calls. Note also in this example how Dr. Memory reports which part of the socketcall system call checks discovered this error.