9 ms·

My dad had a similar story about a bug report. This was back in the day when terminals still used paper rather than CRTs; actual teletypes. The bug report was s

by lambda 6y ago

My dad had a similar story about a bug report. This was back in the day when terminals still used paper rather than CRTs; actual teletypes. The bug report was something like "if I print a page feed on such and such terminal model, it will catch fire." The bug report form (which was paper in those days) had a few of the usual checkboxes and fields to fill in, including one for "is the problem reproducible?" That box was checked. Someone had actually gone to the effort of standing by their terminal with a fire extinguisher, running the same command and putting out the fire when it caught fire again. It turns out the problem was in some software that emulated page feeds by doing repeated line feeds. Some overflow or underflow bug caused an integer to wrap around, so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. It was using those perforated strips at the sides, with the pegs that went into the holes. The pegs and holes weren't perfectly aligned, so the pegs would sometimes clip the holes a bit, causing some bits of paper to shred and get kicked up as dust. Along with a spark, I don't recall if it was from the motor or just static buildup caused by the friction of the paper, and the paper dust would ignite, causing the terminal to catch fire. I just love the image of whoever submitted that bug report, seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible.

segfaultbuserr 6y ago
> so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. [...] causing some bits of paper to shred and get kicked up as dust. Along with a spark [...] causing the terminal to catch fire. Great story! It really gives a new interpretation to the classic phase "halt and catch fire." The original interpretation was the apocalyptic myth that the CPU starts switching the bus really fast, overheats the bus drivers, and eventually ignites the electronics, which doesn't make much sense. Now we have a more realistic one. To be precise, not "halt and catch fire", but "CRLF and catch fire"? BTW, legends also say that the flammability of early printers was the origin of Unix's "lp0 on fire!" joke error message, which can still be seen in Linux for USB printers. /* * Get and print printer errors. */ static const char *usblp_messages[] = { "ok", "out of paper", "off-line", "on fire" };
- bayindirh 6y ago
  The flammability of old printers came from a combination of paper dust, worn out printing ribbon and possible presence of a flammable cleaning solution IIRC. More details are here: https://marc.info/?l=linux-kernel&m=102893054014512&w=2 https://marc.info/?l=linux-kernel&m=102893054014512&w=2 So at the end of the day, it's more of a reality than a joke, sadly.
  - reaperducer 6y ago
    So at the end of the day, it's more of a reality than a joke, sadly. Don't let later-day internet revisionist history take the joy out of you. No matter what the Wikipedia warriors profess, it was real. So much truth has been lost in the last ten years because people who didn't experience the past don't believe the things that happened; and if references aren't a link away, they tell the world things that happened before their time are false.
    - segfaultbuserr 6y ago
      > No matter what the Wikipedia warriors profess BTW, I was reading your Twitter the other day, and saw that you complained that Wikipedia doesn't have any information about TTY - only two paragraphs and nothing more. Now you are here, I have to tell you that you have accidentally set your browser's Wikipedia language to "Simple English" [0], which is a special edition of Wikipedia for English learners, it only has few editors, thus most articles are incomplete. On the other hand, the normal "English" Wikipedia has a fairly standard introduction to TTY [1], around 16 pages on my screen. You've missed a lot, don't forget to switch your language back to "English" if you haven't done it already ;-) [0] https://simple.wikipedia.org/wiki/Teletypewriter https://simple.wikipedia.org/wiki/Teletypewriter [1] https://en.wikipedia.org/wiki/Teleprinter https://en.wikipedia.org/wiki/Teleprinter
      - reaperducer 6y ago
        you have accidentally set your browser's Wikipedia language to "Simple English" I don't understand how that could have happened, so I won't address that issue. But this leaves me baffled: I was reading your Twitter the other day, This has to be the single worst decision you've made this month. As far as I'm concerned, my Twitter feed is write-only memory. The SMS equivalent of dev/null. If you're ever tempted to do so in the future, reconsider. Go for a walk. Write some poetry. Make love to your wife. Do anything else. We get so little time on this planet, please don't waste what you have looking at what I have to say.
SilasX 6y ago
Yeah, that’s dedication! Most bug report handlers today won’t even try to reproduce the bug on a weaker machine. Forget fire risk!
- pmiller2 6y ago
  I don't know about you, but if I ever got a bug report that says "do these things, and it will catch on fire," you can be damn sure I'd be trying to reproduce it with a fire extinguisher nearby. :P
- lambda 6y ago
  Yes! This is why I love this story so much. I triage so many bug reports that don't even have the barest of effort putting in to reproducing or minimizing them, so it's like pulling teeth to figure out what the problem actually is. The fact that someone put enough effort in to reproducing and characterizing a bug report for a bug that actually caused a fire is amazing!
btilly 6y ago
Realistically the printer probably caught fire under normal operations, then they went through everything that happened leading up to it, one step at a time, to figure out what caused it to catch fire. That is what let them submit a bug report with "this causes it to catch fire" rather than, "Printer caught fire randomly." In the process of narrowing down which command did it, they demonstrated reproducibility.
- dannyw 6y ago
  That’s not the definition of reproductivity.
- lambda 6y ago
  Yes, that's pretty much what I was picturing as well. Sorry if it didn't come through in the way I told the story. But yeah, the part of this story that I love is that as someone who reads and triages a lot of bug reports, I'm always disappointed by how few people put in even the barest of efforts to reproduce and characterize a bug. This person, on the other hand, spent the time and effort to reproduce a bug that would actually cause a fire, and characterize it well enough that it could be reproduced and fixed.
m463 6y ago
The IBM mainframe high-speed printers from decades ago made it possible to overprint the same line several times. My memory of this was fuzzy, but I believe when you sent lines to the printer, there was a control code in the first column to have normal printing or to overprint the last line: | v line-of-text +this-overprints-previous-line There were all kinds of things that you could do that were non-optimal, like overprinting lots and lots of stuff until it wore out the paper or making many things print simultaneously. If you did too much, the printer would stop and open the cover - think a 5x5x8 box opening its lid. To be clear - these were basically chain saws with hammers behind the chain all controlled by software.
- dbcurtis 6y ago
  yes. the printers had 132 columns. you sent a buffer of 133 chars, the first being carriage control. blank was line feed, i forget what was page-eject/form-feed (1?? memory fuzzy). + was overprint. As a student, I had a part-time job as an I/O clerk. (feed the card reader, file printouts). We disabled overprint on student jobs because it caused a lot of headaches from bugs. Form feed in an infinite loop was enough hassle. The original IBM printer did not document + for overprint, it was the result of a logic optimization in the controller and someone discovered it. So IBM installed a field change order that disabled that function, but included a switch that for an additional monthly fee would upgrade your printer to a model that supported it. The automatic openning of the lid at the end of a box of paper destroyed coffee cups on a regular basis.
  - unixhero 6y ago
    "Field change order" So essentially a change order carried out by IBM in "the field", meaning your university. Interesting ;)
  - mnaydin 6y ago
    I am reminded of Fortran 77. In Fortran 77, the first character of a record to be printed out determined vertical spacing as follows: Blank One line 0 Two lines 1 To first line of next page + No advance
marcosdumay 6y ago
> seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible. I don't think somebody would repeat the problem just because there's a field in a form. It's way more likely that he reproduced the problem again and again before determining that the LF was causing the fire.
- lambda 6y ago
  That part is a slight amount of hyperbole for humor value. But the fact of the matter is, the submitter did actually reproduce the problem enough times that they were able to effectively characterize the problem. And that's what I love about this story. Given how many bug reports I get in which no effort has been put in to trying to reproduce, characterize, or minimize the problem, I love that this reporter was willing to do enough of that to file a good bug report even for a problem that caused a fire in a piece of expensive equipment.

by lambda 6y ago

segfaultbuserr 6y ago

> so instead of advancing a few lines to the next page, it would try to advance thousands or millions of lines. This particular terminal model was a new, high speed one, so it would try to advance the paper really fast. [...] causing some bits of paper to shred and get kicked up as dust. Along with a spark [...] causing the terminal to catch fire. Great story! It really gives a new interpretation to the classic phase "halt and catch fire." The original interpretation was the apocalyptic myth that the CPU starts switching the bus really fast, overheats the bus drivers, and eventually ignites the electronics, which doesn't make much sense. Now we have a more realistic one. To be precise, not "halt and catch fire", but "CRLF and catch fire"? BTW, legends also say that the flammability of early printers was the origin of Unix's "lp0 on fire!" joke error message, which can still be seen in Linux for USB printers. /* * Get and print printer errors. */ static const char *usblp_messages[] = { "ok", "out of paper", "off-line", "on fire" };

bayindirh 6y ago
The flammability of old printers came from a combination of paper dust, worn out printing ribbon and possible presence of a flammable cleaning solution IIRC. More details are here: https://marc.info/?l=linux-kernel&m=102893054014512&w=2 https://marc.info/?l=linux-kernel&m=102893054014512&w=2 So at the end of the day, it's more of a reality than a joke, sadly.
- reaperducer 6y ago
  So at the end of the day, it's more of a reality than a joke, sadly. Don't let later-day internet revisionist history take the joy out of you. No matter what the Wikipedia warriors profess, it was real. So much truth has been lost in the last ten years because people who didn't experience the past don't believe the things that happened; and if references aren't a link away, they tell the world things that happened before their time are false.
  - segfaultbuserr 6y ago
    > No matter what the Wikipedia warriors profess BTW, I was reading your Twitter the other day, and saw that you complained that Wikipedia doesn't have any information about TTY - only two paragraphs and nothing more. Now you are here, I have to tell you that you have accidentally set your browser's Wikipedia language to "Simple English" [0], which is a special edition of Wikipedia for English learners, it only has few editors, thus most articles are incomplete. On the other hand, the normal "English" Wikipedia has a fairly standard introduction to TTY [1], around 16 pages on my screen. You've missed a lot, don't forget to switch your language back to "English" if you haven't done it already ;-) [0] https://simple.wikipedia.org/wiki/Teletypewriter https://simple.wikipedia.org/wiki/Teletypewriter [1] https://en.wikipedia.org/wiki/Teleprinter https://en.wikipedia.org/wiki/Teleprinter
    - reaperducer 6y ago
      you have accidentally set your browser's Wikipedia language to "Simple English" I don't understand how that could have happened, so I won't address that issue. But this leaves me baffled: I was reading your Twitter the other day, This has to be the single worst decision you've made this month. As far as I'm concerned, my Twitter feed is write-only memory. The SMS equivalent of dev/null. If you're ever tempted to do so in the future, reconsider. Go for a walk. Write some poetry. Make love to your wife. Do anything else. We get so little time on this planet, please don't waste what you have looking at what I have to say.

SilasX 6y ago

Yeah, that’s dedication! Most bug report handlers today won’t even try to reproduce the bug on a weaker machine. Forget fire risk!

pmiller2 6y ago
I don't know about you, but if I ever got a bug report that says "do these things, and it will catch on fire," you can be damn sure I'd be trying to reproduce it with a fire extinguisher nearby. :P
lambda 6y ago
Yes! This is why I love this story so much. I triage so many bug reports that don't even have the barest of effort putting in to reproducing or minimizing them, so it's like pulling teeth to figure out what the problem actually is. The fact that someone put enough effort in to reproducing and characterizing a bug report for a bug that actually caused a fire is amazing!

btilly 6y ago

Realistically the printer probably caught fire under normal operations, then they went through everything that happened leading up to it, one step at a time, to figure out what caused it to catch fire. That is what let them submit a bug report with "this causes it to catch fire" rather than, "Printer caught fire randomly." In the process of narrowing down which command did it, they demonstrated reproducibility.

dannyw 6y ago
That’s not the definition of reproductivity.
lambda 6y ago
Yes, that's pretty much what I was picturing as well. Sorry if it didn't come through in the way I told the story. But yeah, the part of this story that I love is that as someone who reads and triages a lot of bug reports, I'm always disappointed by how few people put in even the barest of efforts to reproduce and characterize a bug. This person, on the other hand, spent the time and effort to reproduce a bug that would actually cause a fire, and characterize it well enough that it could be reproduced and fixed.

m463 6y ago

The IBM mainframe high-speed printers from decades ago made it possible to overprint the same line several times. My memory of this was fuzzy, but I believe when you sent lines to the printer, there was a control code in the first column to have normal printing or to overprint the last line: | v line-of-text +this-overprints-previous-line There were all kinds of things that you could do that were non-optimal, like overprinting lots and lots of stuff until it wore out the paper or making many things print simultaneously. If you did too much, the printer would stop and open the cover - think a 5x5x8 box opening its lid. To be clear - these were basically chain saws with hammers behind the chain all controlled by software.

dbcurtis 6y ago
yes. the printers had 132 columns. you sent a buffer of 133 chars, the first being carriage control. blank was line feed, i forget what was page-eject/form-feed (1?? memory fuzzy). + was overprint. As a student, I had a part-time job as an I/O clerk. (feed the card reader, file printouts). We disabled overprint on student jobs because it caused a lot of headaches from bugs. Form feed in an infinite loop was enough hassle. The original IBM printer did not document + for overprint, it was the result of a logic optimization in the controller and someone discovered it. So IBM installed a field change order that disabled that function, but included a switch that for an additional monthly fee would upgrade your printer to a model that supported it. The automatic openning of the lid at the end of a box of paper destroyed coffee cups on a regular basis.
- unixhero 6y ago
  "Field change order" So essentially a change order carried out by IBM in "the field", meaning your university. Interesting ;)
- mnaydin 6y ago
  I am reminded of Fortran 77. In Fortran 77, the first character of a record to be printed out determined vertical spacing as follows: Blank One line 0 Two lines 1 To first line of next page + No advance

marcosdumay 6y ago

> seeing the "is it reproducible" checkbox on the form, and standing by the terminal with a fire extinguisher to put it out while doing the same thing to make sure the problem was reproducible. I don't think somebody would repeat the problem just because there's a field in a form. It's way more likely that he reproduced the problem again and again before determining that the LF was causing the fire.

lambda 6y ago
That part is a slight amount of hyperbole for humor value. But the fact of the matter is, the submitter did actually reproduce the problem enough times that they were able to effectively characterize the problem. And that's what I love about this story. Given how many bug reports I get in which no effort has been put in to trying to reproduce, characterize, or minimize the problem, I love that this reporter was willing to do enough of that to file a good bug report even for a problem that caused a fire in a piece of expensive equipment.