I was reading today about every 30 GB Zune failing at exactly the same time.
As it turns out, the cause is probably an infinite loop that will only appear on the 366th day of a leap year (see this write-up).
So just curious...have you ever written an infinite loop that made it all the way to production without being detected?
No, the worst I have done is code longitude between -pi and pi, when the documentation stated it was 0 and 2pi. This made it into production and I had a wave of users complain the software was behaving strangely.
This was clearly a QA issue and nothing to do with me :-)
EDIT: I should add that this slipped through because for half the world, the software would behave correctly and the initial intent of the software was not for the other side of the world.
I had a super obvious infinite loop go through code inspection, then QA, and right into production.
Way before I started doing TDD though.
Yes. Every release has at least one. )
void main(void)
{
StartMyInterruptBasedTaskSchedulerHere();
for(;;)
{
// This is my infinitely looping background process
PlaySomeBackgroundMusic();
}
}
I write few programs without an implicit infinite loop. Usually a message dispatcher of some kind.
A co-worker of mine wrote one. It attempted a micro-charge of a users account, and on failure, assumed the charge hadn't gone through, so it re-tried. However, in one scenario, the charge was successful, but a failure was reported anyway.
The software went into an infinite loop charging the users account over and over. Even at a micro-charge rate, it ultimately caused one user to be charged hundreds of dollars.
Server daemon processes are routinely designed to have an infinite loop that runs forever. Yes, I have programs like that in production; one is running on my machine now - it was started on 2008-09-15. It'll stop when I kill it, or when the machine is rebooted.
Also, think of web servers such as Apache. Also think of database servers such as Informix (or Oracle, or DB2, or ...). Also think of programs such as cron. Lots of programs are designed to have an infinite loop in them.
What they aren't designed to do is have a useless loop that simply jams up the machine. The useful programs have a loop that waits for something to happen and responds to the action when it does happen.
Embedded systems are always running in an infinite loop, where it looks for user input and runs the device outputs in the meantime. And yes, the compiler still complains that
while(1) {
// check inputs
// service outputs
}
Is infinite and will never terminate. Well, yeah.
Yes. HTML tag remover that looped from each '<' to the following '>', or just forever if there was no following '>'. I was young and foolish then. Now I'm only foolish.
Have you ever heard of Robocode? The robots are all written with an infinite loop in the run() method.
Almost. The bug was found by a sister company.
I inherited a proxy process that, amongst other things, stripped telnet information. As it turned out, after 15 minutes it would be sent a keep alive packet. I can't remember whether the packet was just empty or an empty record (IBM 3270 buffered mode terminal emulation). I had a loop in my InputStream.read(byte[],int,int) implementation to make sure it only returned when it had some data. In the case where data was received, but there was nothing to send on, it happened to continually loop without trying to read more data from the socket.
To make matters worse, the thread ran at highest priority. On an NT box it took a while to be able to kill off the process.
Just about every answer here mentions some situation where an infinite loop was/is actually intentional and nothing to be embarrassed about. I will step up and offer myself as a subject of ridicule so that others may learn from (or laugh at) my mistake:
Basically, I had code like this that ran on a Threading.Timer:
private Queue<Snapshot> snapshots;
// code code code
public void SaveSnapshots() {
while (snapshots.Count > 0) {
Snapshot snapshot = snapshots.Dequeue();
snapshot.SaveToFile();
}
}
At some point it was decided that we should hold (i.e., not save) Snapshots until a certain condition was reached, so the above code became:
private Queue<Snapshot> snapshots;
// code code code
public void SaveSnapshots() {
while (snapshots.Count > 0) {
Snapshot snapshot = snapshots.Dequeue();
if (snapshot.AnalyticsComplete) {
snapshot.SaveToFile();
} else {
snapshots.Enqueue(snapshot);
}
}
}
Testing this quickly in the development environment (with only a fraction the number of simultaneous threads as production) didn't uncover any hiccups. It went on to production. Then, before long, it became apparent that something was badly slowing down our processing.
To my credit (?), I figured out the problem and deployed the fix within about ten minutes.
Also, as if it even needs to be said: our company does not have a testing department.
My company recently released a javascript-heavy web application that uses the jquery.address plugin to provide back button support and deep linking. Thanks to a Safari bug with location.hash, entering any deep link URL that happened to include a hash character (such as http://www.mysite.com/#obj{ s: "#test" }) caused Safari to fire address changed events continuously, which effectively hung the browser.
While technically not our infinite loop, we should have caught it in testing. Fortunately the development team caught the error before any customers.
Yes, on purpose, as part of a system shutdown routine. Clear interrupts and do a tight loop until user pushes hardware reset or powers the machine off.
A technique to avoid infinite loops (used in nuclear power plant software):
void criticalRoutine() {
int iterations = 10000;
while( criticalCondition() && iterations-- > 0 ) {
criticalWork();
}
}
Now the loop cannot run an infinite number of times.
FYI, IANANPPSD.