Question

Scratching my head here: I have an application which works fine in Debug+Release if started from Visual Studio 2010, in both Debug and “Run without Debugging”. If I run the same app from the command line, with the same settings, I see a different behaviour though. In particular, the code that runs differently is:

const List& vl = nDesc.Get<List> ("slots");

int index = 0;
for (auto it = vl.begin (), end = vl.end (); it != end; ++it)
{
    desc.units [index++] = Parse (Tree (*it));
    // If I access it again here, e.g.
    // Log::Info (std::distance (vl.begin (), it))
    // this works always
}

I would assume that’s a race condition, but the code is fully single-threaded. Interestingly, adding some random code does not make it work (i.e. just Logging a string is not enough.) Oh, and this loop is run only once, ever.

The data in desc is the same, dumping it to a file after the loop shows the same data has been written. Moving the loop up and down around in that piece of code does not help; neither does changing the auto to List::const_iterator help.

Any ideas where to start debugging this?

[Update] Disabling optimizations on this function does not fix it for Release, but I can attach the debugger and see that everything in there works as expected. Yet I don’t get the correct program behaviour. Stills works with “Run without Debugging” and “Run with Debug”, too.

Answer 1

I suspect that the problem is related to an uninitialized heap memory block.

The main difference between starting it without debugging and attaching it to the debugger and starting it from the debugger is that in the second case the Windows debug heap is used.

The Windows Debug Heap pre-fills the memory handed to the clients with a particular pattern (0xBAADF00D IIRC), and is activated whenever an executable is started with a debugger attached. Even if it is made to make uninitialized memory bugs discovery easier (because it fills the memory with a “strange” pattern), in this case probably it’s masking your problem, since it becomes evident only when no debug heaps are used (so the uninitialized memory blocks are probably filled with zeros).

Notice that this particular code block may be just the tip of the iceberg, the problem may be originated in a different location and emerge just here.

Good luck in finding the bug, this exact kind of problem happened to me too with a third-party library, and, despite some days of searching, I had to give up.

(Incidentally, the Windows Debug Heap is unrelated from the CRT Debug Heap, that instead is activated only in Debug builds of the executable, and, IIRC, it fills the memory with the 0xCD pattern)