You're relatively close to deadline, run the program, all's ok. Suddenly crash (hopefully it was a crash). Turns out it's while freeing memory. You realize you have memory corruption.

OMG Panick Attack!!! you remove a piece of code that seems troubling, and everything's fine. Put it back. Corruption. Your heart starts beating faster than normal.

Is it that code?? Or is it that it's just triggering a deeper problem somewhere else completely unrelated???? Is it a recent bug or something you've introduced like, 3 months ago????

I've just had one. Luckily the troublesome code was actually the root cause of the problem. All is well now. I came here just to relieve my pain. I needed to get it out of my system by talking here with other programmers that will understand me. Stupid mistake by the way (like most of bugs).

Don't you hate that feeling? Memory corruption is one of computer bugs that creeps me most. All the other I can bust them pretty quickly; but corruptions are the hardest to fine. Sometimes I wish there were some kind of All mighty monitoring software that would raise an exception each time you get out of a single byte. May be enabling DEP would help? Yes, I know about Purify, tried the trial a month ago when I thought I had one. Didn't convince me at all.

Thanks for listenting. It's therapeutic
I feel better now

We once had a funny bug when an integer was assigned the value 0, but when checking the value against 0 on the next instruction, the comparison would fail.
We were all rather confused about what on earth was going on. Turned out to be memory corruption somewhere along the line. That day made me question the very fundamentals of programming. I enjoy those days.

By next instruction you mean exactly the next instruction after the assignment, or that it was the next time you touched that integer again?

Towards the end of my first real game project, an error started popping up where all of the ships would draw fine, but the 2nd or 3rd ship would appear as the game's logo... which was an entirely different game state and had already been freed by that point. That was my first real experience with the "how in the world can I even begin to track this down?"-type corrupted memory errors.

I've since that time learned that whenever something is going "impossibly" wrong in my code, no matter how much it looks like the compiler's fault, it's always my fault in the end. Only once, in six years of programming, has it really been not my fault (or the fault of 3rd party libraries).. and that one time, it still wasn't the compilers' fault ([size=2]it was an unrelated videocard driver I had installed a month beforehand that was defective in certain conditions and caused multiple programs to break, not just mine, and it just happened that I hadn't worked on that code for a few weeks since the video card driver was installed, so my program magically "broke" despite the last time I worked on it, it was functioning fine. Took me three or four days of aggravation wondering what had happened).

I find the largest source of issues like that is either misunderstanding documentation about something, or having something documented completely wrong. Usually the misunderstanding, but when it is simply wrong can make for some interesting adventures.

One time I had access to a rather large cluster owned by a research group. Massive distributed thing with sites all over the globe, and running this cool light weight custom OS linking everything together. I got drawn into a project to provide some wrappers for the boiler plate stuff required by apps to run on the custom cluster. Basically priority, load balancing, security spec flagging, etc. Stuff so the high level system could know how the program was suppose to run, and how it could handle stuff.

It has been so many years that I can't remember which way it was. But basically there was a disagreement between docs and implementation on the topic of passing a set of values as 1/0 or 1/-1. Pretty sure docs said 1/0, and it was implemented as 1/-1 for an efficiency reason that I can't recall anymore.

We ran a simple test program, a port of a system wide load balance and data passing. Should have taken 10 minutes for a scheduled down time. We managed to critically lock the system for over about two weeks. (The 'failsafe' systems kept storing the error, and carrying it through on a system boot.) Needless to say myself and my project lead were not looked fondly upon at first. After the source of the problem was traced back to "Not Us" they lightened up a bit, but one of the engineers responsible for the original systems got a broken nose.

Moral of the story: Check your docs, and even geeks can still carry a mean left hook.

Memory breakpoints! It's one of those features of VS you never really use, but when you do use it, you thank god it exists!

As for my funky stories, In my current game I suddenly encountered a bug where, after about 10 seconds, the main ambient light would start to flicker for a second or two, before completely going dark. And then, the gravity would invert.

Which is peculiar, considering ambient light calculation is hardcoded into the shader at the time, and we had no way of modifying gravity on the fly...

My worst one (took a few of us about a month to fix - maybe $10000 in salaries!) occurred about a month before gold -- turns out a render-target wasn't allocated enough RAM, so it was overflowing into random other resources, such as vertex buffers, causing random graphical corruptions, at random points in time, but this depended on the order that assets were constructed, which depended on background loading scheduling and the order that you progressed through the levels.

Memory breakpoints were a huge red-herring too, because a co-processor was responsible for the write to RAM, not the CPU!

I can not really empathize with these issues, never having written big projects in low level languages. At most mid-sided ones, and then in modern low level languages like D.

Nowadays, if I use a low level language, its always as an extension module to another project in a high level language. That also seems to work wonders for me; I rarely do resource management within the low level language, and the code-paths within the unsafe context tend to be short and easy to debug, and usually have a reference implementation in the high-level language as well, as a fallback to isolate problems

I must say I have a hard time coming up with a project id say makes sense to implement in, say, pure C++. In all my projects, 90% of time is spent in 10% of the code, if not something more extreme.

Memory breakpoints! It's one of those features of VS you never really use, but when you do use it, you thank god it exists!

As for my funky stories, In my current game I suddenly encountered a bug where, after about 10 seconds, the main ambient light would start to flicker for a second or two, before completely going dark. And then, the gravity would invert.

Which is peculiar, considering ambient light calculation is hardcoded into the shader at the time, and we had no way of modifying gravity on the fly...

Depending on the game, I would consider fixing a bug like that, and then re-implementing the 'features' as part of the game play.

Memory breakpoints! It's one of those features of VS you never really use, but when you do use it, you thank god it exists!

^^ THIS. A thousand times.

I have felt your pain many times. And I will likely feel it again in the future.

Memory breakpoints ease the pain of memory corruptions, like Novocaine vs. a dentists drill during a root canal, or general anesthesia vs. open heart surgery.