Dr Memory and the mysterious uninitialized read

Question

The code below doesn't do anything interesting, but the mystery is why would Dr Memory think there's an unitialized read? Any ideas?

#include <memory>

int main(int argc, const char* argv[])
{
    int aa[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};

    std::unique_ptr<int[]> p {new int[10]};

    for (auto i = 0; i < 10; ++i) {
        p[i] = aa[i];
    }

    return 0;
} // <-- Dr Memory says UNINITIALIZED READ here

EDIT: Here's the full error details.

Error #1: UNINITIALIZED READ: reading 0x0028ff20-0x0028ff24 4 byte(s)
# 0 __mingw_glob                              [src/main.cpp:14]
# 1 _setargv                                  [src/main.cpp:14]
# 2 __mingw_CRTStartup
# 3 mainCRTStartup
# 4 ntdll.dll!RtlInitializeExceptionChain    +0x62     (0x772c8fe2 <ntdll.dll+0x38fe2>)
# 5 ntdll.dll!RtlInitializeExceptionChain    +0x35     (0x772c8fb5 <ntdll.dll+0x38fb5>)
Note: @0:00:00.297 in thread 9780
Note: instruction: cmp    (%esi) $0x0040a11e

Answer 1

The line indicated in your main function is not the line where the error occurred. The error occurred in __mingw_glob as indicated by the stack trace, and this is occurring before any of your code is called. (This is the function which expands filename wildcards passed on the command line. On Linux this job is done by the shell, but on Windows it is the responsibility of the C Runtime.)

In other words it is occurring in the mingw library. It's likely that this is harmless false positive and you should simply add an exclusion.

I suggest that probably Dr Memory has wrongly identified this as uninitialized since it was initialised by the operating system before any of your code ran, or by code which ran before DrMemory was initialised, or because it was passed to a system call which does not in fact read the memory but only writes to it.

Why is it showing the wrong line in your function?

Debuggers try to show you relevant information by default. Since it is generally much more likely that your code is buggy rather than library code, the debugger will show the most recent instance of your code on the call stack. For example, if an error occurs in the implementation-specific depths of a call to free it is unlikely to be the library heap code which is at fault, so instead your code which called free would be identified as the likely culprit.

In your case there is none of your code on the call stack, so the algorithm is failing to locate any and is showing you an erroneous location.