I'm about halfway through Day 035, and I've run into the following:
The program hangs after an indeterminate amount of time - it often seems to happen when the edge of the drawn area reaches a chunk boundary, but this isn't always the case.
When this happens and I break, no source is available but the disassembly usually shows us to be in a call to NtWaitForMultipleObjects.
My (limited) understanding is that the program is waiting for a signal from the OS and not receiving it. Has anyone else run into this?
(I noticed this happening after I started drawing more tiles on the screen - near the beginning of day 035).
That is very low-level function in Windows. What functions are in call stack? If it doesn't show call stack, right unknown entry (where it shows only address) and click "Load debugging symbols" (or something called similarly).
Basically find out what code calls this function and examine that.
When I posted, it was happening every time I ran the program within about 30 seconds; for whatever reason, I haven't been able to reproduce it since your post (no changes to my code).
If it happens again, I'll check the call stack and post here.
Just a small note: when breaking into a running program, you must be careful to ensure that the displayed disassembly is actually the thread that you want to see. Often times it will not be. I would encourage you to use the "Threads" debug window, and to look through the threads of the program when you break, to see if the "Main Thread" is actually a different thread than the one you are seeing by default in Visual Studio. Switching to the main thread might help you track down the problem!
Ok, it started happening again, and I was able figure it out, thanks to Casey's tip -
I checked the main thread this time, and it showed me that the function call that hangs is Sleep().
Back when we added fixed frame rate, I found I was going over the target frame duration by a little bit relatively often. I tried mitigating the issue by subtracting a millisecond from the amount of time we should sleep, meaning we'd spin and hog the CPU for a millisecond. It seemed to work fine, at the time.
Turns out that if there wasn't a full millisecond available to sleep, the DWORD-stored number of milliseconds to sleep was truncated to 0, so I was subtracting 1 millisecond from 0 and the underflow resulted in me requesting a LOONG sleep from the OS.