Another one: it took me three days with Visual Basic scripting for a NI software. Totally random crashes on my machine, unable to reproduce on others (but it was hard to try on other platforms), some emailing with the Support, when it turned out it was a bug in their software, my code was just fine.

The bug (memory corruption) was caused by a feature, that's behaviour was changed in the very version of the software I had. I guess they didn't debug it yet...

I was using Racket the other day and searching a string with some regex, trying to find a backslash followed by a particular set of characters in a sub-capture group. I had the regex "\\(some|subcapture|group)" and it wouldn't catch things it should've matched, like "\a" (which, escaped would be like "\\a"). I figured out faster than I expected to that "\\(" actually means "a single escaped backslash that is escaping the parenthesis" and the correct regex I wanted was really "\\\\(some|subcapture|group)" (just to match something like "\a"). It wasn't long until all my regexes became a mess of backslashes...

Some recent ones for me have been working with Android, where everything is pretty much an asynchronous event system, but only certain functions can be called from certain threads (or perhaps two events can happen simultaneously and call the same function and cause conflicts), where I'd get various exceptions regarding thread conflicts or "not called from the main/GUI thread" exceptions. Grrrr.

I had a fun one the other month. We were working on a C project (most of the code was written by my boss so I wasn't familiar with it) that kept randomly crashing. It was so sporadic that I was guessing we were trashing memory somehow, but it was totally unclear where. I was the only one working with the code too, because my boss moved on to other stuff. Our investor/client wanted the prototype to show to other potential investors to raise capital, but the program was simply unstable. Anyway, I finally found the bug (after my boss had been digging through the code for hours): in one point, an array was being allocated with calloc (which takes the size of each element and the number of elements in an array to create) and reallocated with realloc (which just takes the total size in bytes, not the number of elements or the size of each element). The code was passing the number of elements to realloc (instead of the total number of bytes), as if it were calling calloc, so instead of growing the array it was shrinking it and we'd eventually trash the heap as the program went on. Honestly, I don't even think calloc should exist. Inconsistent calling semantics do no one any favors.

Ooooh, and another one. Signals. Everyone learns about using signals in C in school, and they always show how to use the signal() function to register callbacks. What everyone forgets to mention is that the signal() function is more or less deprecated and it is recommended to not use it because its effects vary across UNIX implementations. Plus, it's got undefined behavior in multithreaded apps. Well, our program was multithreaded and despite registering for callbacks, our program would still get killed from signals we should've been catching. It took some googling to find sigaction(), which is the "proper" way to do it that actually handles multithreaded programs. Screw you signal(), and may people stop teaching others about you.

In PHP, when I realized 0 == "pizza".

Is this the sort of thing that makes people say "TRWTF is PHP?"

Yes. Javascript has some funny ones too, and don't get me started on languages where null compared to anything is null (because all operations with null return null), resulting in hacks like isnull() and such. And in case you're curious about that piece of code: "pizza" is converted to an integer, and since it has no digits in it, it turns into 0 =/

As for gotchas: once I was filling a buffer using a pointer (i.e. *ptr++ = ...). Problem: the buffer got resized by calling realloc as needed as more data was processed. Guess what happened when the memory block was moved around when reallocated. It was so bad that the debugger couldn't tell where the error happened and valgrind outright crashed. Had to use printfs and place breakpoints around to figure out what line was crashing.

At least that was an easy fix: instead of doing *ptr++ = ...; do ptr[pos] = ...; pos++;

It probably didn't throw an exception because it was technically writing to valid memory. It would only throw an exception when it tries to write to an address without any memory assigned. Same goes for reading.

And yeah, C arrays have that issue, it's done for performance reasons (not checking the size of the array every time it's accessed, which in turn involves knowing the size of the array too). Remember C was made when computers were pretty slow. It was probably better to do the checks only when needed (e.g. if you're handling a range of data you could do the check once outside the loop) than every time you accessed the data.

C++ vectors also have this catch, surprisingly: [] doesn't do boundary checks. To do boundary checks you need to use the at() member function. So e.g. instead of doing vector[4] you'd do vector.at(4). Fun stuff.