I'm ashamed to admit that I've still got a hefty little piece of VBScript at a grocery store that does some price & cost number crunching for them; it features a very funky two-stage inner loop which will occasionally produce random numbers if you feed in very large data sets. Two different pretty sharp people have spent a lot of time trying to track it, and nobody can find it. One of them looked at it and about cried when he realized how it was supposed to work.
Not too long ago, I had to figure out a timing issue in some JavaScript for a photo gallery. It's about as multi-tasking as JavaScript can get, and the code has its own task manager. Each new task was supplied with a UID, which was just the number of milliseconds since 01/01/1970. Occasionally, however, a task wouldn't fire. It would get queued, and then disappear from the queue, but never run. Every time I set breakpoints in the script, used alerts, or otherwise examined the code as it ran, everything worked fine.
It took me most of an afternoon to realize that occasionally two different tasks were being created within the same millisecond, and getting the same UID. Subsequently, one of the tasks would stomp on the other one. I kicked myself for knowing better than that and wrote a more reasonable UID hash.
Years ago, one of the first languages I got to play with was Pascal, on a pre-7.5 Mac OS. I was using THINK Pascal at the time, and having fun, but occasionally my program would bomb out in really interesting ways. It took me a long while to trace the bug to a problem in the compiler, where a struct that was supposed to be 4 bytes long was getting loaded on to the stack in 6 bytes. Usually this wouldn't be an issue, except that one of my functions was popping the struct off the stack as a longint, instead of as the actual struct. Whoops.
But, probably the most fun "bug" I ever figured out wasn't really a software issue at all. I worked in the data processing department of a Bay Area school district. Despite being one of the better school districts in the area, and having enough spare change for student A/V programs and the like, a lot of their systems ran on an ancient Unisys mainframe, COBOL74, and reel tapes. (Hey, it worked. Unisys mainframes have incredible recovery abilities.)
The reel tapes had a little reflective strip near the end of the tape, and the tape drive had this optical sensor that would pick up the reflection as the strip flew by, and dismount the tape.
It was the damnedest thing -- sometimes, usually in late Spring or early Summer, a tape would be in the middle of some operation, and it would dismount, even though it was nowhere near the end of the tape.
I was sitting in the room one day when it happened, and turned around in time to see a perfect little sunbeam sneaking through the blinds and shining right on the drive's optical sensor, fooling it.
Not too long ago, I had to figure out a timing issue in some JavaScript for a photo gallery. It's about as multi-tasking as JavaScript can get, and the code has its own task manager. Each new task was supplied with a UID, which was just the number of milliseconds since 01/01/1970. Occasionally, however, a task wouldn't fire. It would get queued, and then disappear from the queue, but never run. Every time I set breakpoints in the script, used alerts, or otherwise examined the code as it ran, everything worked fine.
It took me most of an afternoon to realize that occasionally two different tasks were being created within the same millisecond, and getting the same UID. Subsequently, one of the tasks would stomp on the other one. I kicked myself for knowing better than that and wrote a more reasonable UID hash.
Years ago, one of the first languages I got to play with was Pascal, on a pre-7.5 Mac OS. I was using THINK Pascal at the time, and having fun, but occasionally my program would bomb out in really interesting ways. It took me a long while to trace the bug to a problem in the compiler, where a struct that was supposed to be 4 bytes long was getting loaded on to the stack in 6 bytes. Usually this wouldn't be an issue, except that one of my functions was popping the struct off the stack as a longint, instead of as the actual struct. Whoops.
But, probably the most fun "bug" I ever figured out wasn't really a software issue at all. I worked in the data processing department of a Bay Area school district. Despite being one of the better school districts in the area, and having enough spare change for student A/V programs and the like, a lot of their systems ran on an ancient Unisys mainframe, COBOL74, and reel tapes. (Hey, it worked. Unisys mainframes have incredible recovery abilities.)
The reel tapes had a little reflective strip near the end of the tape, and the tape drive had this optical sensor that would pick up the reflection as the strip flew by, and dismount the tape.
It was the damnedest thing -- sometimes, usually in late Spring or early Summer, a tape would be in the middle of some operation, and it would dismount, even though it was nowhere near the end of the tape.
I was sitting in the room one day when it happened, and turned around in time to see a perfect little sunbeam sneaking through the blinds and shining right on the drive's optical sensor, fooling it.