4 ms·

This is hilarious! Some of you might recall how all Zune devices died on 12/31/08. Windows_Globalization_Calendar_AddMonths_System_Int32 was the root of it al

by cududa 7y ago

This is hilarious! Some of you might recall how all Zune devices died on 12/31/08. Windows_Globalization_Calendar_AddMonths_System_Int32 was the root of it all, apparently. (For further reading on the Zune outage: https://techcrunch.com/2008/12/31/zune-bug-explained-in-detail/ https://techcrunch.com/2008/12/31/zune-bug-explained-in-deta...)

King-Aaron 7y ago
Also reminds me of the old "Printer won't print on Tuesdays" bug https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28 https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...
- aurbano 7y ago
  > This bug is causing printing using the brother cups drivers to fail on Tuesdays. Absolutely loved reading through the bug! haha
- codezero 7y ago
  Wow that’s a zinger! The underlying issue with the file utility is bonkers! https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619
- decasia 7y ago
  I mean, this is a great example of how complex systems exhibit unpredictable, emergent behavior. You think you are doing some process X (say, printing), but it turns out that X relies on some more generic layer Y (a file utility layer) which is running a set of arbitrary filter functions that you have no idea exist. One of these filters then happens to check for some magic strings in your data. And these hardcoded strings turn out to be strings that can also occur in unrelated kinds of data... What's the underlying issue, really? Is it that detecting file types by checking for magic strings is always a bad idea? Or is it something more basic about the architecture here, more like the leaky abstractions problem?
  - anyfoo 7y ago
    The problem here is that the printing pipeline uses the ‘file’ tool to detect what the data to be printed is (e.g. PostScript), but ‘file’ can only ever guess the content of a file. It is a heuristic, and as soon as you have a heuristic, you will always run into cases where it gives a wrong result (otherwise it’s not a heuristic anymore, obviously). So, I would actually disagree with the author that it is strictly a bug in the ‘file’ utility, as there is simply no completely reliable way to determine intended file type by just looking at the content[1]. You have to transmit that information out of band, and this is why we have MIME types sent through Content-type: headers in HTTP or email headers. File extensions are another method (though also ambiguous: .TXT and .EXE are almost certain, but a .DB or .BAK can be one of many things). CUPS is probably applying this heuristic for convenience (“send anything to your printer and it just prints!”), at the cost of correctness. [1] A simple proof for that is the existence of “polyglots”, which in this context are source code that happens to be a valid program in two or even more different programming languages (often doing the same or similar things for sport). Were CUPS to differentiate printing based on the programming language, e.g. by applying different syntax highlighting, it would not know what language to choose, and without out of band information there hardly even is a “right” answer. In practice though you can detect a file type more reliably than ‘file’, but at much more complexity than “let’s check some magic numbers in some offsets to give the user an idea of what this might be”, and it still wouldn’t be perfect.
    - ygra 7y ago
      It still is a bug in the data for file, though. As the respective bug states, the spaces should have been escaped and so file actually misidentified everything with »Tue« in that place of the file contents as the wrong type.
iClaudiusX 7y ago
Technically, the Zune bug didn't kill the device. The bug sent it into an infinite boot loop until the following day when the leap year calculation could return. But yes, the difficulty in verifying a correct implementation of date and time calculation calls out for a standard test apparatus to "prove" correct results for a defined scope.
- avip 7y ago
  I once stupidly implemented a "date math" feature, and after introducing numerous bugs in production opted to use https://svn.python.org/projects/sandbox/trunk/datetime/test_datetime.py https://svn.python.org/projects/sandbox/trunk/datetime/test_... as my ref. test (which exposed numerous other bugs). Likely not full coverage of all date-time related bizarrities, yet a useful resource.
  - karlp 7y ago
    For date and time, Arrow is a lifesaver in python https://arrow.readthedocs.io/en/latest/ https://arrow.readthedocs.io/en/latest/
  - nkozyra 7y ago
    > I once stupidly implemented a "date math" feature I believe this to be one of those rites of passage for any programmer.
    - WorldMaker 7y ago
      That and/or "rip out this idiot date math library written by your predecessor and try to use an industry standard library instead". Especially the karma of first one then the other.
      - jandrese 7y ago
        About the only way to keep your sanity is to treat dates in only one of two ways, depending on the context: 1. As a string you don't touch 2. Convert to seconds_since_the_epoch immediately. Convert back only when necessary (when printing to the screen or sending to a SQL query for example). This calc problem is somewhat unique because months and years aren't fixed length and it's probably bad if your program says Feb 1 to March 1 is less than a month, or Jan 1 2000 to Jan 1 2001 is a year and a day. Or if Jan 1 2001 to Jan 1 2002 is a year and a quarter of a day. And then you have to account for those occasional years that are divisible by 4 but are not a leap year. And then you have to account for when someone asks for the difference between September 1 1752 and September 20 1752. Pretty soon you're remembering why rules 1 and 2 exist. It should be noted that calc.exe gets this wrong in many ways.
darekkay 7y ago
Some similar stories: "unit tests fail when run in Australia" [1] and "the case of the 500-mile email" [2]. Many interesting debugging stories are collected in this GitHub repository [3]. [1] https://github.com/angular/angular.js/issues/5017 https://github.com/angular/angular.js/issues/5017 [2] http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html [3] https://github.com/danluu/debugging-stories https://github.com/danluu/debugging-stories
- s3arch 7y ago
  Thank you so much.
- lamby 7y ago
  > unit tests fail when run in Australia I've found countless ones of these. Some of them in date/time/timezone handling libraries.. :/

by cududa 7y ago

King-Aaron 7y ago

Also reminds me of the old "Printer won't print on Tuesdays" bug https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28 https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161...

aurbano 7y ago
> This bug is causing printing using the brother cups drivers to fail on Tuesdays. Absolutely loved reading through the bug! haha
codezero 7y ago
Wow that’s a zinger! The underlying issue with the file utility is bonkers! https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619 https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619
decasia 7y ago
I mean, this is a great example of how complex systems exhibit unpredictable, emergent behavior. You think you are doing some process X (say, printing), but it turns out that X relies on some more generic layer Y (a file utility layer) which is running a set of arbitrary filter functions that you have no idea exist. One of these filters then happens to check for some magic strings in your data. And these hardcoded strings turn out to be strings that can also occur in unrelated kinds of data... What's the underlying issue, really? Is it that detecting file types by checking for magic strings is always a bad idea? Or is it something more basic about the architecture here, more like the leaky abstractions problem?
- anyfoo 7y ago
  The problem here is that the printing pipeline uses the ‘file’ tool to detect what the data to be printed is (e.g. PostScript), but ‘file’ can only ever guess the content of a file. It is a heuristic, and as soon as you have a heuristic, you will always run into cases where it gives a wrong result (otherwise it’s not a heuristic anymore, obviously). So, I would actually disagree with the author that it is strictly a bug in the ‘file’ utility, as there is simply no completely reliable way to determine intended file type by just looking at the content[1]. You have to transmit that information out of band, and this is why we have MIME types sent through Content-type: headers in HTTP or email headers. File extensions are another method (though also ambiguous: .TXT and .EXE are almost certain, but a .DB or .BAK can be one of many things). CUPS is probably applying this heuristic for convenience (“send anything to your printer and it just prints!”), at the cost of correctness. [1] A simple proof for that is the existence of “polyglots”, which in this context are source code that happens to be a valid program in two or even more different programming languages (often doing the same or similar things for sport). Were CUPS to differentiate printing based on the programming language, e.g. by applying different syntax highlighting, it would not know what language to choose, and without out of band information there hardly even is a “right” answer. In practice though you can detect a file type more reliably than ‘file’, but at much more complexity than “let’s check some magic numbers in some offsets to give the user an idea of what this might be”, and it still wouldn’t be perfect.
  - ygra 7y ago
    It still is a bug in the data for file, though. As the respective bug states, the spaces should have been escaped and so file actually misidentified everything with »Tue« in that place of the file contents as the wrong type.

iClaudiusX 7y ago

Technically, the Zune bug didn't kill the device. The bug sent it into an infinite boot loop until the following day when the leap year calculation could return. But yes, the difficulty in verifying a correct implementation of date and time calculation calls out for a standard test apparatus to "prove" correct results for a defined scope.

avip 7y ago
I once stupidly implemented a "date math" feature, and after introducing numerous bugs in production opted to use https://svn.python.org/projects/sandbox/trunk/datetime/test_datetime.py https://svn.python.org/projects/sandbox/trunk/datetime/test_... as my ref. test (which exposed numerous other bugs). Likely not full coverage of all date-time related bizarrities, yet a useful resource.
- karlp 7y ago
  For date and time, Arrow is a lifesaver in python https://arrow.readthedocs.io/en/latest/ https://arrow.readthedocs.io/en/latest/
- nkozyra 7y ago
  > I once stupidly implemented a "date math" feature I believe this to be one of those rites of passage for any programmer.
  - WorldMaker 7y ago
    That and/or "rip out this idiot date math library written by your predecessor and try to use an industry standard library instead". Especially the karma of first one then the other.
    - jandrese 7y ago
      About the only way to keep your sanity is to treat dates in only one of two ways, depending on the context: 1. As a string you don't touch 2. Convert to seconds_since_the_epoch immediately. Convert back only when necessary (when printing to the screen or sending to a SQL query for example). This calc problem is somewhat unique because months and years aren't fixed length and it's probably bad if your program says Feb 1 to March 1 is less than a month, or Jan 1 2000 to Jan 1 2001 is a year and a day. Or if Jan 1 2001 to Jan 1 2002 is a year and a quarter of a day. And then you have to account for those occasional years that are divisible by 4 but are not a leap year. And then you have to account for when someone asks for the difference between September 1 1752 and September 20 1752. Pretty soon you're remembering why rules 1 and 2 exist. It should be noted that calc.exe gets this wrong in many ways.

darekkay 7y ago

Some similar stories: "unit tests fail when run in Australia" [1] and "the case of the 500-mile email" [2]. Many interesting debugging stories are collected in this GitHub repository [3]. [1] https://github.com/angular/angular.js/issues/5017 https://github.com/angular/angular.js/issues/5017 [2] http://www.ibiblio.org/harris/500milemail.html http://www.ibiblio.org/harris/500milemail.html [3] https://github.com/danluu/debugging-stories https://github.com/danluu/debugging-stories

s3arch 7y ago
Thank you so much.
lamby 7y ago
> unit tests fail when run in Australia I've found countless ones of these. Some of them in date/time/timezone handling libraries.. :/