I once wrote some code that unintentionally smashed the interpreter's error-tracking data structure at compile-time. If you had even the slightest error in that

I once wrote some code that unintentionally smashed the interpreter's error-tracking data structure at compile-time. If you had even the slightest error in that module, like a misspelled variable name or type error or unknown function, you'd just get "Unknown error". I never bothered to fix it, so I believe it's still in production. You better hope you're not assigned to maintain that module. The one bug at my last job that gave me trouble was one where somebody deep in the stack called the C close() on a filehandle managed by the interpreter. The bug report was "My reports are showing up empty when I run them". The language interpreter kept track of its filehandles separately and wasn't informed about the close, and this led to an off-by-one error when you later went to write to a language-managed filehandle. I noticed stat'ing the filehandle gave a different inode than the temporary file it was supposed to be opening. I moved over to an ext4 filesystem so I could use the debugfs command to look up the inode, but the error only showed up on the same xfs filesystem. A brute-force search of the filesystem turned out that the report was being written to one of my Perl source files, which was opened read-only and so the writes were being rejected. The commit that introduced the error caused it by adding an include, which shuffled the order that filehandles get allocated, which exposed the off-by-1 error that had been around for 10 years which usually didn't cause any trouble. Took me a solid week to track that one down.