I've had a compiler error that was very sneaky and only happened in certain build configurations. Because it was a compiler error, it was caught before heading into production, but it happened just before the final build, so it lead to a stressful hour or two for me ("Hey, the thing we're supposed to ship very soon fails compilation on the platform we're shipping it on!"). Here is a much simplified version of the issue:

    doSomething(),
    DEBUG_MACRO("Print some text");

And mistakenly put a comma instead of semicolon at the end of the first row. I didn't notice the typo, because it compiled and ran just fine: the thing on the left of the comma and the thing on the right were both expressions, which is valid with the C "comma operator". But, on some build settings, "DEBUG_MACRO" became an if statement (it expanded to something like "if (debuggingIsOn) ..."), which is not an expression and thus not valid with the comma operator.

Lesson learned: always build and test all build configurations continuously during development. Don't leave it to the last minute.

We had the software version defined as a macro in the header file. This worked absolutely fine for version 0 to version 7 and then stopped compiling at version 08.

It turned out, the original author had written it as a 2 digit number for consistency, like this: 03

In C, a leading 0 indicates the number is octal, so 07 is a valid number, but 08 is not.

Apple's Goto Fail bug is similar but not exactly what you're looking for: https://dwheeler.com/essays/apple-goto-fail.html

At university (a long time ago) on my first excursion with the Modula II compiler on the Vax, I accidentally inserted a # as the first character in a long source file. The compiler dutifully reported every line in the file as being in error.

I was inexperienced at reading compilerese (and source control and diffing were not commonplace at that time) and it took me a good day to extricate myself from my bewilderment.

I'm still mildly amused that such a small change to a more-or-less working codebase produced such generous output...

Not a semicolon, but...

"The most expensive hyphen in history"

https://en.wikipedia.org/wiki/Mariner_1

Not a semi-colon but -

Setting up a GPO to push Microsoft updates to clients in an AD domain, I spent ~8 hours debugging why the clients couldn't connect to the WSUS server. It turned out that there was trailing whitespace in the server URL text field that was getting parsed.

As a side note, this type of story IMO doesn't actually play that well in interview situations.

Everytime I receive input from a human source I remove leading and trailing whitespace. (I have never had a situation where it was needed)

Far too many instances of copy/pastes including those bloody things.

Every time i need to copy/paste some important text into something, i run it through notepad so it kills all the (meta)code that may be hidden deep inside the text. I know it may not kill the whitespaces, but it's usually the first thing i do when i get copy/paste crap like that.

Yes, although I group it as "misplaced/missing" semi-colon. Although the common case of mixing a control statment/block open/close with the misplaced semi-colin generaly seems to be a pretty easy bug to find unless its buried in firmware or some other hard to debug place. OTOH, most decent static analysis tools will warn on constructs with unusual semi-colon indent/block open sequences these days.

AKA

  if ((unusual condition) || (something other condition)); {
     do_something(); 
  }

will buy a nice fat warning the same as using "=" in a control statement. Bonus if the semi-colon comes from a macro so its not actually visible in the code sequence.

Not a real story, but in theory a missing semicolon in javascript can lead to unexpected results. The semi-colon is optional but missing it will cause issue if the following line starts with an opening bracket (and maybe other chars too). For instance:

    const foo = [['bar'], ['baz']];
    [0, 1].forEach(x => x*x);

foo will be the array, as expected. But forget the semicolon and foo is assigned the return of forEach, a.k.a undefined. The syntax is valid, but is not evaluated to what you would naively expect.

I don't think I've had it happen in running software but back when I was learning I wasted many hours trying to find where my error was with super unhelpful c++ errors, usually to find the problem was the crappy books I was learning from. In running software I've come across extra semi-colons causing issues, like when c and bash are mixed up:

  if (foo);
    fooBar();

Fortunately I've only wasted a couple of hours on that one.

I once spent two weeks tracking down a scheduler bug (it would stop scheduling threads and stall forever) to two assembly-language instructions that were in the wrong order, and would cause a timer interrupt to never fire if there was an interrupt between them. Swapping the two instructions fixed the bug.

So, not a missing semicolon, but pretty close . . .