Comment On Classic WTF: The Bug That Shut Down Computers World-Wide

Fist of teh year

Apparently all the old Wang VS programmers went on to the Zune software team.

WOW! I don't think I've even SEEN a Wang since then. Was that what happened to them then?

And we've been living on borrowed time ever since.

> Specifically, it mistakenly incremented the zero-indexed day-of-year
> for all day-of-years that are equal to 0 in a leap-year.

I may be misinterpreting the bug, but if it only incremented day-of-year 0 of a leap year, e.g. 1/1/1984, and did not increment any other day-of-year, couldn't this problem have been temporarily solved by waiting until day-of-year 1, e.g. 1/2/1984?

On 1/2/1984 the temporary files generated would have expiration dates equal to the current date and the temporary files generated on 1/1/1984, with their expiration dates of 1/2/1984, could also be removed without raising an error.

I suppose I'm just wondering why they sprung for overnight shipping, getting it there on the 2nd, when they had four years to send out the patch.

Hehe, wang.

Whatever became of this programming language "so simple a secretary could master it"?

Here's the Zune bug:

BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)

{

    int dayofweek, month, year;

    UINT8 *month_tab;



    //Calculate current day of the week

    dayofweek = GetDayOfWeek(days);



    year = ORIGINYEAR;



    while (days > 365)

    {

        if (IsLeapYear(year))

        {

            if (days > 366)

            {

                days -= 366;

                year += 1;

            }

        }

        else

        {

            days -= 365;

            year += 1;

        }

    }

http://pastie.org/349916

No post about Wangs is complete without a link to Freezepop's song - Do you like my Wang

Ironic that the Zune bug is also because of a programming oversight on a leap year.

So the zune bug would cause an infinite loop when days is 366 on a leap year?

merichar:

> Specifically, it mistakenly incremented the zero-indexed day-of-year
> for all day-of-years that are equal to 0 in a leap-year.

I may be misinterpreting the bug, but if it only incremented day-of-year 0 of a leap year, e.g. 1/1/1984, and did not increment any other day-of-year, couldn't this problem have been temporarily solved by waiting until day-of-year 1, e.g. 1/2/1984?

On 1/2/1984 the temporary files generated would have expiration dates equal to the current date and the temporary files generated on 1/1/1984, with their expiration dates of 1/2/1984, could also be removed without raising an error.

I suppose I'm just wondering why they sprung for overnight shipping, getting it there on the 2nd, when they had four years to send out the patch.

The bug had flooded the storage with dud temporary files. The wangs were unable to boot with no storage. Presumably they had to overnight some means to free it up, say a deletion program that ran bare-metal and didn't try to write anything (or even extra storage).

What strikes me as odd is that for all of these date-related problems, nobody ever tried setting the system date ahead or to a leap year or anything else. But I guess until you see something fail spectacularly, you don't worry about it much. Though I wonder if the Zune fiasco will change that—that's some pretty awful publicity.

Well thank Bob such a silly bug would never make it into a product these days.

There were three big rages back in the 1980’s: Rubik’s cubes, Molly Ringwald, and Wangs. While I’m sure you are all familiar with those(...)

So, who the hell is/was Molly Ringwald?





Also, happy new year to everyone!

Shmork:

What strikes me as odd is that for all of these date-related problems, nobody ever tried setting the system date ahead or to a leap year or anything else. But I guess until you see something fail spectacularly, you don't worry about it much. Though I wonder if the Zune fiasco will change that—that's some pretty awful publicity.

Well, if 'it works', why test it further? After all, time == money...

"grinded"?

Why would the temp file module need to do any arithmetic in the first place? Just set the file expiration time to now() and you're sorted. The impression I get from the article is that it was taking now(), converting it to YYYY-MM-DDTHH:MM:SS and then converting it back. Is that correct?!

sluq:

"grinded"?

Thank you.

Captcha: secundum - when just one trojan isn't enough?

Lupus.Umbrae:

There were three big rages back in the 1980’s: Rubik’s cubes, Molly Ringwald, and Wangs. While I’m sure you are all familiar with those(...)

So, who the hell is/was Molly Ringwald?





Also, happy new year to everyone!

You know, looks like you answered your own question there.

Shmork:

What strikes me as odd is that for all of these date-related problems, nobody ever tried setting the system date ahead or to a leap year or anything else.

The article makes it sound like it's only a problem on 1 January <leapyear>. So while they probably tried and tested against the leap day proper, and the days around it, they wouldn't have noticed anything on those other 365 days.

Interesting WTF.

Someone Important:

Shmork:

What strikes me as odd is that for all of these date-related problems, nobody ever tried setting the system date ahead or to a leap year or anything else. But I guess until you see something fail spectacularly, you don't worry about it much. Though I wonder if the Zune fiasco will change that—that's some pretty awful publicity.

Well, if 'it works', why test it further? After all, time == money...

and

knowledge == power...

Crash Magnet:

knowledge == power

That omits a few important steps in between...

knowledge == academia
academia == gas-bag
gas-bag == wind
wind == electrical generation
electrical generation == power

See? It's obvious!

Crash Magnet:

Someone Important:

Shmork:

What strikes me as odd is that for all of these date-related problems, nobody ever tried setting the system date ahead or to a leap year or anything else. But I guess until you see something fail spectacularly, you don't worry about it much. Though I wonder if the Zune fiasco will change that—that's some pretty awful publicity.

Well, if 'it works', why test it further? After all, time == money...

and

knowledge == power...

Sorry can't help myself.

Chung Mee: Opium is my business. The bridge mean more traffic. More traffic mean more money. More money mean more power.
Lawrence Bourne III: Yeah, well, before I commit any of that to memory, would there be anything in this for me?
Chung Mee: Speed is important in business. Time is money.
Lawrence Bourne III: You said opium was money.
Chung Mee: Money is Money.
Lawrence Bourne III: Well then, what is time again?

Kender:

Here's the Zune bug:

BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)

{

    int dayofweek, month, year;

    UINT8 *month_tab;



    //Calculate current day of the week

    dayofweek = GetDayOfWeek(days);



    year = ORIGINYEAR;



    while (days > 365)

    {

        if (IsLeapYear(year))

        {

            if (days > 366)

            {

                days -= 366;

                year += 1;

            }

        }

        else

        {

            days -= 365;

            year += 1;

        }

    }

http://pastie.org/349916

Now why the heck would you put that inside of a while loop? That's just begging for a screw-up and an infinite loop. Wow.

Wow, I would have to say that is one crazy bug!

jess
www.privacy.es.tc

ckd:

Apparently all the old Wang VS programmers went on to the Zune software team.

Actually, the buggy code that locked up the Zunes is from Freescale. (It's part of their clock driver) I can only assume that there are other devices out there suffering from a similar problem.

It is made by Microsoft, you know ;)

Kender:

Here's the Zune bug:

BOOL ConvertDays(UINT32 days, SYSTEMTIME* lpTime)

{

    int dayofweek, month, year;

    UINT8 *month_tab;



    //Calculate current day of the week

    dayofweek = GetDayOfWeek(days);



    year = ORIGINYEAR;



    while (days > 365)

    {

        if (IsLeapYear(year))

        {

            if (days > 366)

            {

                days -= 366;

                year += 1;

            }

        }

        else

        {

            days -= 365;

            year += 1;

        }

    }

http://pastie.org/349916

Had to run that through my "code review module" a couple of times. (Hey - it's New Year's Day.) "1" and "60" work just fine. What could go wrong? Then I plugged in "365" and saw day 0 pop out. Ouch. I feel for the code review team that missed that.

[quote user="jimlangrunner]Had to run that through my "code review module" a couple of times. (Hey - it's New Year's Day.) "1" and "60" work just fine. What could go wrong? Then I plugged in "365" and saw day 0 pop out. Ouch. I feel for the code review team that missed that.[/quote]

I think the bigger problem is that IsLeapYear is true and yesterday was day 366.

Dan:

Actually, the buggy code that locked up the Zunes is from Freescale. (It's part of their clock driver) I can only assume that there are other devices out there suffering from a similar problem.

No, look at Microsoft's comments at the top of the file. If Freescale didn't accept Microsoft's EULA, Freesoft isn't authorized to use Freescale's source code. Neither can any other device makers.

Lupus.Umbrae:

So, who the hell is/was Molly Ringwald?

"Yes, you're a total fag."

Reading the code, it appears the reason it's in a while loop is that "days" can continue accumulating indefinitely while the device is off.

The while loop allows them to increase the number of years by the appropriate amount even if it has been off for a prolonged time, such as several years.

I'm not seeing a much simpler way to implement this than this while loop. You can't exactly just use integer division here. I don't think using "while" is the WTF. It's just a bug.

please s/grinded/ground/ in above article.

Ah, the Wang. Yeah, I've almost never heard of it before except in the Do It Yourself song:
"Oh, IBM, DEC, and Honnywell, HP, DG, and Wang / Amdahl, NEC, and NCR, they don't know anything. They make big bucks for systems so they never want it known that you can build a mainframe from the things ya find at home."

http://www.bsutton.com/Bill/Filk/diyAnnotated.txt

--
Furry cows moo and decompress.

Yesterday did not mark the anniversary of "October 2nd, 2007"

Shmork:

What strikes me as odd is that for all of these date-related problems, nobody ever tried setting the system date ahead or to a leap year or anything else. But I guess until you see something fail spectacularly, you don't worry about it much. Though I wonder if the Zune fiasco will change that—that's some pretty awful publicity.

Well, some of us *do* think to test our code with leap years. Some of us even go so far as to test our code with Dec 31, the year before a leap year, and the first and last day of every month in the leap year, and Jan 1 of the year after the leap year. Others of us go even more pedantic and write an automated test loop that will test every day in the leap year.

Obviously, these bugs happen to people who don't do this.

Of course, then there's my coworker who wrote an automated test loop that tested every day in 2000... Sigh. (And, yes, his code did have a leap year bug.)

Slackmaster K:

Yesterday did not mark the anniversary of "October 2nd, 2007"

It wasn't the anniversary of the story being posted - it was the anniversary of the story itself.

Worked on a Wang back then. . . Whenever new software was being acquired, the first question the software salesman would ask is "How big is your Wang?"

So, who the hell is/was Molly Ringwald?

Let me Google that for you...

i like that. learned something new.

[quote user="guest"][quote user="jimlangrunner]Had to run that through my "code review module" a couple of times. (Hey - it's New Year's Day.) "1" and "60" work just fine. What could go wrong? Then I plugged in "365" and saw day 0 pop out. Ouch. I feel for the code review team that missed that.[/quote]

I think the bigger problem is that IsLeapYear is true and yesterday was day 366.[/quote]

Yes, 365 breaks out of the loop, but 366 doesn't, and on a leap year, there is no way to decrement days.

I suppose the way to fix it is collapse the two 'if's into

  if (IsLeapYear(year)

        && (days > 366))

Then again, they should be working today again anyway.

Dirk Diggler:

Chung Mee: Opium is my business. The bridge mean more traffic. More traffic mean more money. More money mean more power.

There were three big rages back in the 1980’s: Rubik’s cubes, Molly Ringwald, and Wangs.

... and Wang Chung! (Thanks, Diggler)

P.S. everybody have fun tonight

I worked for Wang in those days -- on the VS from 1976 to 1987. The bug first occurred in 1976 on the LAST (366th) day of a leap year. It botched the file's expiration date such that you could not delete a file which had not "yet" expired.

They swore it was fixed for 1980. It wasn't. It occurred again in 1984 and yet again at the end of 1988. Knowledgable system administrators ("system operators" back then) would set the date back to 30 December on the 31st, then reset it correctly on 1 January of the following year.

Wang Laboratories was dissolved completely in the mid-90s.

Once again we see the importance of boundary classes in testing. Testing every date in a specific year (or multiple years) is sometimes impossible, almost always unneccesary, and will surely kill ROI. It is much easier to find the end-points(New Year's) or known trouble spots (Feb 29), and then test n+1 and n-1.

When you consider that this is a basic lesson one learns when they begin QA, and take into account how many headaches developers have been through with datesin general, it's really a no-brainer.

It is much easier to find the end-points(New Year's) or known trouble spots (Feb 29), and then test n+1 and n-1.

...and n, of course. Sorry, I need to unit test my comments.

Can anyone say...Zune, and the Z2K9 bug?

Well, next time I ask a completely stupid question such as "Who is Molly Ringwald?" I will use <irony> or <trollmode> tags, okay?

Shmork:

What strikes me as odd is that for all of these date-related problems, nobody ever tried setting the system date ahead or to a leap year or anything else. But I guess until you see something fail spectacularly, you don't worry about it much. Though I wonder if the Zune fiasco will change that—that's some pretty awful publicity.

We have been hit with some date related issues. Its not just leap year, we found some other magic dates over time that cause problems. Nothing like that early morning call that Tokyo started trading and the whole system is down and every customer is calling. Fix it now.

I have suggested to our QA team that they run with the dates in one lab set 3 months ahead. Call it the future lab. That way, if we hit a strange date related problem we have three months before all the customers call us.

No, they don't do it.

Code Slave:

I suppose the way to fix it is collapse the two 'if's into
[code]
if (IsLeapYear(year)

&& (days > 366))

Well, that would have the effect of breaking in a non-infinite loop way in leap years. The calander would still go Dec. 29, Dec. 30, Jan. 1, Jan. 1 at end of a leap year/start of the next year.

Shmork:

...

Of course, then there's my coworker who wrote an automated test loop that tested every day in 2000... Sigh. (And, yes, his code did have a leap year bug.)

Am I missing something here? That sounds like a *good* way to catch a leap year bug.