Question

I’m using C# with XNA in Visual Studio 2010 Ultimate.

I have a program that performs some calculations not involving timing, threads or anything else that might effect the result if I stopped execution to debug, but didn’t then do anything before continuing with running the rest of the program.

At it’s end the program prints some output to the screen.

In this program repeatedly pressing F10 until the output is shown produces a different result than either just pressing F5 to run while debugging or running without debugging, which both produce the wrong result.

This shows a run with individual F10 steps.

The program runs a simple two player game many times, the game involves moving a counter around on a board, both players are automated and move at random. 100 games occur for each line, some games don’t end before a certain number of goes have expired and aren’t counted. As can be seen from these 8 sets of random games, it’s quite well balanced, at least for players that take moves at random regarding who will win and who will loose.

The following image shows a run with F5.

Somethings not right here, game runs don’t effect each other and sets are just a place to stop and start counting, they don’t effect anything. However very much unlike in the first image we won all 100 games in a row, twice but then lost 100 brand new unrelated games in a succession 2 sets later.

The obvious answer given the 2nd image is that there is something wrong with my program logic, however there isn’t. And it’s frustrating that when I go to debug the problem running the debugger slowly so I can see whats happening fixes it.

What could be wrong?

Answer 1

If this is not using Threads, then my main suspicion is that something is probably using the System.Random class. Make sure to use the same instance of the Random class for each call to Next().

The likely problem is that, if you call a method using Random in quick succession (ie: when running normally, and not in the debugger), and create a new instance each time, you may very likely be seeding the random instance with the same seed, since it’s based off the system clock. “Slowing it down” via debugging would prevent this from occurring, which is why the behavior would be better during a stepping debug session.