Tabs are pure evil. Well, OK maybe not, but I hate them. Part of the problem is that different editors and tools treat the tab character differently. Some always use 4 chars, some use 8, some indent to specific column numbers, some use a user-selected number of spaces. If everything is tabbed and you use a single set of consistent tools, that's no problem. The problem is when spaces and tabs get mixed together and/or you need to work in a heterogenous environment things get ugly really quickly. The basic fact is that you can't trust tabbed text to look the same and be lined up the same from one computer setup to the next. And if you mix in someone using spaces, things go really screwey when someone else opens the file with a different tab behavior and suddenly the spaced line is out of whack through nobody's fault. (And please don't tell me that every code line MUST begin with a tab like it's a make file or something). None of that happens if everyone uses spaces. Then the text is formatted the same regardless of what editor/tool/platform/etc you use. This benefit far outweights the "symmetry" of a backspace removing 4 spaces at once. Particularly when most good code editors can unindent you automatically regardless of tabs.

Yeah, if it's just one person, it's pretty unobtrusive. It's only after my kids got in the act that I had any problems with it.

You may not have to *start* them via the Steam gui, but every one I've seen requires Steam to be running in the background, even if you are in offline mode. Steam modifies the game executables to require this so the games fire up Steam even when you directly click on the game executable. I have around 80 Steam-based games now and have yet to see one that doesn't work that way. Not even for indie games that would have no DRM or just a serial key if I had purchased them outside of Steam.

Steam was fine until my kids got old enough to start wanting to play the games I bought on Steam: Steam's DRM requires you to be logged in. There's an offline mode, but you have to be logged in to activate it, so if your net connection dies, you're stuck and can't activate the offline mode. The offline mode also seems to occasionally decide you need to log in again, at which point you can't use your Steam games until you've logged in. Further, you can only have one computer logged into Steam at any time, so if you log in from a second computer, your first computer is immediately logged out (and it'll usually kick you out of the game). So you can't play a game on Steam while your child/wife/girlfriend plays an entirely different Steam game on a different computer - unless you monkey with the offline mode on the two. Now imaging adding a 3rd or 4th computer to the mix.

Glad I was able to help!

Ahh, the fact that it runs thousands of times OK before crashing changes things a bit. I don't suppose it's so convenient as to always crash at the exact same point/iteration? If you really think the local variable is getting suddenly changed, and that's causing the problem, you should try to prove that or disprove it: - Definitely try moving it to a global. - Do the other local variables in the function all look OK when you look at the in the dump? Is myNumberOfElements the last variable declared in the function? It would be odd if only myNumberOfElements was getting corrupted and nothing else around it (unless AllocArray is taking a reference to it and corrupting it there). You could try placing "guard" variables or the same size, with known values, declared right before and after myNumberOfElements and seeing if those get alterred in any way during the crash. - store the result of myCalculation in two or three separate variables (in different locations - a global, a heap var, and the stack) that you can compare in the dump. No way they can all get corrupted in the same way without everything else in the program also doing so. - log the value to a file when received from myCalculation and again immediately before the AllocArray call. One or more of thse things should be sufficient to prove or disprove your theory and give you enough tot go on for the next step

Cool stuff. What is this all for, if I may ask?

So the test for myNumberOfElements being out of range happens right before the call to AllocArray? That's not a lot of time for it to be getting corrupted by your code before the call. It seems definitely possible the value seen in dump file is corrupt as a result of the crash rather than the cause of the crash. But... - As already asked, how are you looking at the dump file? - Does the debug version of the program work OK? - Have you tried turning off or lowering optimization? Try this first if you haven't! - Are you sure that AllocArray is capable of handling 100000 elements? Some things to maybe try: - Can you modify your program to output myNumberOfElements right before the call? - Create a global variable to hold the result of myCalculation and pass that in to AllocArray. If this is memory/stack corruption happening in your function, it's unlikely it would step on the global var in the same way. - Hardcode the value being passed in to AllocArray. If you can find out and use the real result of myCalculation, even better. Does this still crash? Either way, this will tell you a lot about what's going on.