“My wife has complained that OpenOffice will never print on Tuesdays” (2009)

Did this get fixed, 7 years later?<p>Yesterday, we had a story about Microsoft&#x27;s disk management service using lots of CPU time if the username contained &quot;user&quot;. Microsoft&#x27;s official reply was not to do that.<p>I once found a bug in Coyote Systems&#x27; load balancers where, if the USER-AGENT ended with &quot;m&quot;, all packets were dropped. They use regular expressions for various rules, and I suspect someone typed &quot;\m&quot; where they meant &quot;\n&quot;. Vendor denied problem, even after I submitted a test case which failed on their own web site&#x27;s load balancer.<p>Many, many years ago, I found a bug in 4.3BSD which prevented TCP connections from establishing with certain other systems during odd numbered 4 hour periods. It took three days to find the bug in BSD&#x27;s sequence number arithmetic. A combination of signed and unsigned casts was doing the wrong thing.

Reminds me of my favorite bug story from my own career. It was in my first year or two out of college. We were using a commercial C++ library for making HTTP calls out to another service. The initial symptom of the bug was that random requests would appear to come back with empty responses -- not just empty <i>bodies</i>, but the entire response was empty (not even any headers).<p>After a fair amount of testing, I was somehow able to determine that it wasn&#x27;t actually random. The empty response occurred whenever the size in bytes of the entire request (headers and body together) was exactly 10 modulo 256, for example 266 bytes or 1034 bytes or 4106 bytes. Weird, right?<p>I went ahead and worked around the problem by putting in a heuristic when constructing the request: If the body size was such that the total request size would <i>end up</i> being close to 10 modulo 256, based on empirical knowledge of the typical size of our request headers, then add a dummy header to get out of the danger zone. That got us past the problem, but made me queasy.<p>At the time, I had looked at the code and noticed an uninitialized variable in the response parsing function, but it didn&#x27;t really hit me until much later. The code was something like this:<p><pre><code> void read_status_line(char *line) { char c; while (c != &#x27;\n&#x27;) { c = read_next_byte(); *(line++) = c; } } </code></pre> Obviously this is wrong because it&#x27;s checking <i>c</i> before reading it! But why the 10 modulo 256 condition? Of course, the ASCII code for newline is 10. Duh. So there must have been an earlier call stack where some other function had a local variable storing the length of the request, and this function&#x27;s <i>c</i> variable landed smack-dab on the least-significant byte of that earlier value. Arrrrgh!

The title reminds me of &quot;the 500 mile email&quot;<p><a href="http:&#x2F;&#x2F;www.ibiblio.org&#x2F;harris&#x2F;500milemail.html" rel="nofollow">http:&#x2F;&#x2F;www.ibiblio.org&#x2F;harris&#x2F;500milemail.html</a>

The most interesting part of this story to me is actually that his wife noticed that the printer didn&#x27;t work on Tuesdays. I&#x27;d have never, ever put that together, no matter how many times I saw it succeed or fail. I&#x27;d actually be more likely to figure it out by debugging the CUPS script than I would be observing my printer&#x27;s behavior. Can a lot of people pick up on correlations like that? &quot;Ever notice how it&#x27;s always Tuesday when the printer won&#x27;t work?&quot;

My most memorial bugfix was when I was on a team ,temporary ,that did email encryption&#x2F;decryption. They had one customer where some mails could not get decrypted, they had been figthing with this for one year, no one could figure out what was going on. I told them to do a dump for a week with the good and bad emails. After one week I was given the dump of files, looked at the count of bad vs good, did some math in my head and said: &quot;Hmm, it appears that about 1&#x2F;256 mails is bad.That could indicate that the problem is releated to a specific byte having a specific value in the random 256 bit AES key. If there is a specific value giving problems it is probaly 0x00 and the position I would guess being at the last or first byte.&quot;<p>I did a check by decoding all SMIME mails to readable text with openssl- sure, all bad emails had 0x00 as the least signicant byte. Then i looked at asn1 spec and discovered it was a bit vague about if the least significant byte had to be there if it was 0x00. I inserted a line into the custom written IBM 4764 CCA driver written in c called by JNI. Then all emails decrypted.<p>The team dropped their jaws- they had been figthing with it for 1 year and I diagnosed the bug only by looking at the good&#x2F;bad ratio :)<p>I might remember some details wrong- but the big picture is correct :)

The TL;DR is that the &quot;file&quot; utility was miscategorising files that had &quot;Tue&quot; in the first few bytes of a file as an Erlang JAM file, with knock on effects for PostScript files generates with a header comment with Tue in the date.

The weirdest case at my tenure as a neighborhood computer tech was a personal notebook computer that would not boot up at the customer&#x27;s apartment. Of course we assumed user error, but further investigation revealed that if the computer were running as it approached the home, it would bluescreen about a block away.<p>We guessed it was due to some kind of RF interference from a transmitter on the apartment building. Removing the WiFi module and the optical drive had no effect, so we further guessed it was interference within the motherboard or display. Rather than investigate further, we replaced the notebook at that point.

I have an anecdote, which isn&#x27;t mine but comes from someone I know personally. This guy was working as a service tech, and was called out to diagnose a problem with a computer that had been recently moved. It worked most of the time, but any attempt to use the tape drive failed within a certain number of seconds (this was long ago, when tape drives were still a thing). Everything had worked fine before the move, and diagnostics didn&#x27;t show anything out of place. Then he happened to look out the window - this was a military installation, and there was a radar dish rotating nearby. The failures occurred exactly when the radar dish was pointed their direction. It turns out the computer had been moved up one floor, which strengthened the interference just enough to cause the failure.

But &quot;Tue&quot; is not at the fourth byte in the example, which has:<p><pre><code> %%CreationDate: (Tue Mar 3 19:47:42 2009) </code></pre> Something munged he the data. Perhaps some step which removes all characters after %%, except those in parentheses?<p><pre><code> %%(Tue Mar 3 ...) </code></pre> Now we&#x27;re at the fourth byte. Another hypothesis is that the second incorrect match is kicking in. That is to say, some fields are added above %% CreationDate such that the Tue lands on position 79. The bug that was fixed in the magic database is this:<p><pre><code> -+4 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2 -+79 string Tue Jan 22 14:32:44 MET 1991 Erlang JAM file - version 4.2 ++4 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2 ++79 string Tue\ Jan\ 22\ 14:32:44\ MET\ 1991 Erlang JAM file - version 4.2 </code></pre> (This is a patch of a patch: a fix to a an incorrect patch.) There are two matches for this special date which identifies JAM files: one at offset 4, but a possible other one at offset 79 which will cause the same problem.<p>The real bug here is arguably the CUPS script. It should identify the file&#x27;s type <i>before</i> munging it. And it shouldn&#x27;t use a completely general, highly configurable utility whose data-driven file classification system is a moving target from release to release! This is a print script, so there is no reason to suspect that an input file is a Doom WAD file, or a Sun OS 4 MC68000 executable. The possibilities are quite limited, and can be handled with a bit of custom logic.<p>Did Brother people write this? If so, I&#x27;m not surprised.<p>Nobody should ever write code whose correct execution depends on the &quot;file&quot; utility classifying something. That is, not unless you write your own &quot;magic&quot; file and use only that file; then you&#x27;re taking proper ownership of the classification logic, such that any bugs are likely to be your own.<p>The fact that file got something wrong here is a red herring; the file utility is wrong once in a while, as anyone knows who has been using various versions of it regularly regularly for a few decades. Installations of the utility are only suitable for one-off interactive use. You got a mystery file from out of the blue, and need a clue as to what it is. Run file on it to get an often useful opinion. It is only usable in an <i>advisory</i> role, not in an <i>authoritative</i> role.

I&#x27;ve noticed that printing is still one of the poorest UX aspects of *nix&#x2F;OSS and regularly seems to suffer from errors so egregious that they can only be attributed to OSS devs not dogfooding these features. I&#x27;m assuming they just don&#x27;t print much (I mean, we ALL print less than 20 years ago, but all the more reason to test these features which, when you need them to work you REALLY need them to work).

Stuff like this is why I find &quot;Synthetic Biology&quot; so fucking scary.

During my studies I had a course called &quot;Advanced Network Administration&quot;. I learnt about the OSPF routing protocol and its Quagga [1] implementation and I had to prepare a simple installation that consisted of 3 Linux machines. They were connected with cheap USB network adapters.<p>After everything was configured I started the Quagga daemons and somehow they just didn&#x27;t want to talk to each other. I&#x27;ve opened tcpdump to see what happens and the OSPF packets were exchanged properly. After a while the communication and routing was established. I thought that maybe the services just needed some time to discover the topology.<p>I&#x27;ve restarted the system to see if it&#x27;s able to get up automatically, but the problem reoccured - daemons just didn&#x27;t see each other. Again, I launched tcpdump, tweaked some settings and now it worked - until it didn&#x27;t a few minutes later.<p>It take me a long time to find out that diagnostic tool I&#x27;ve used had actually changed the observed infrastructure (like in the quantum world). tcpdump enables the promiscuous mode on the network interfaces and apparently this was required for Quagga to run on the cheap USB ethernet adapters. I&#x27;ve used the ifconfig promisc and after that the OSPF worked stable.<p>[1] <a href="http:&#x2F;&#x2F;www.nongnu.org&#x2F;quagga&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.nongnu.org&#x2F;quagga&#x2F;</a>

CERN: LEP data confirm train time tables <a href="http:&#x2F;&#x2F;cds.cern.ch&#x2F;record&#x2F;1726241" rel="nofollow">http:&#x2F;&#x2F;cds.cern.ch&#x2F;record&#x2F;1726241</a><p>CERN: Is the moon full? Just ask the LHC operators <a href="http:&#x2F;&#x2F;www.quantumdiaries.org&#x2F;2012&#x2F;06&#x2F;07&#x2F;is-the-moon-full-just-ask-the-lhc-operators&#x2F;" rel="nofollow">http:&#x2F;&#x2F;www.quantumdiaries.org&#x2F;2012&#x2F;06&#x2F;07&#x2F;is-the-moon-full-ju...</a>

Near the end of that post, the commenter suggested a fix that includes the most qualified Useless Use of Cat entry[0] that I&#x27;ve ever seen!<p><pre><code> cat | sed ... &gt; $INPUT_TEMP </code></pre> [0] <a href="http:&#x2F;&#x2F;porkmail.org&#x2F;era&#x2F;unix&#x2F;award.html#cat" rel="nofollow">http:&#x2F;&#x2F;porkmail.org&#x2F;era&#x2F;unix&#x2F;award.html#cat</a>

Wait till you see where they found the print server!<p><a href="http:&#x2F;&#x2F;www.informationweek.com&#x2F;server-54-where-are-you&#x2F;d&#x2F;d-id&#x2F;1010340" rel="nofollow">http:&#x2F;&#x2F;www.informationweek.com&#x2F;server-54-where-are-you&#x2F;d&#x2F;d-i...</a>?

Surely the real bug is the reliance on the &#x27;file&#x27; utility in the first place? It attempts to quickly identify a file that could be literaly anything so it&#x27;s not surprising (and indeed should be expected) that sometimes it gets it wrong.<p>I don&#x27;t know the details of the CUPS script but presumably it can only deal with a small number of different file types. Implementing it&#x27;s own detection to positively identify PS vs whatever other formats it deals with vs everything else would be far more robust.

One of our users complained that she could no longer print PDF documents. Everything else, Word, Excel, graphics, worked fine, but when she printed a PDF ... the printer did emit a page that - layout-wise - pretty much looked like it was supposed to, except all the text was complete and utter nonsense.<p>Or was it? I took one of the pages back to my desk, and later in the day I had an idle moment, and my eyes wandered across the page. The funny thing is, if I had not known what text was supposed to be on the page, I would not have noticed, but the text was not random at all. Instead, all the letters had been shifted by one place in the alphabet (i.e. &quot;ABCD&quot; became &quot;BCDE&quot;).<p>I went back to the user and told her to check the little box that said &quot;Print text as graphics&quot; in the PDF viewers printing dialog, and voila - the page came out of the printer looking the way it was supposed to.<p>Printing that way did take longer than usual (<i>a lot longer</i>), but at least the results were correct.<p>To this day, I have no clue where the problem came from, and unfortunately, I did not have the time to investigate the issue further. I had never seen such a problem before or after.<p>In a way it&#x27;s part of what I like about my job: These weird problems that seem to come out of nowhere for no apparent reason, and that just as often disappear back into the void before I really understand what is going on. It can be oh-so frustrating at times, but I cannot deny that I am totally into weird things, so some part of me really enjoyed the whole experience.

I love the modification that pipes the output of cat into sed; doesn&#x27;t he realize that cat is redundant at that point?

I once had the case with a desktop system that when you sat down and started typing it often hardware reseted. Turned out Dell left some metal piece in the case which was hanging between the case and the motherboard (in those few millimeter) and with some stronger desk vibration caused a shortcut.

Here&#x27;s a great collection of classic bug reports (including the never-printing-on-tuesdays): <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10309401" rel="nofollow">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=10309401</a>

My 6502 based FORTH systems would sometimes crash for no apparent reason after I tweaked some code and recompiled it. Whenever it got into crashy mode, it would crash in a completely different way, on a randomly different word. I&#x27;d put some debugging code in to diagnose the problem, and it would either disappear or move to another word! It was an infuriating Heizenbug!<p>It turns out that the 6502 has a bug [1] that when you do an indirect JMP ($xxFF) through a two byte address that straddles a page boundary, it would wrap around to the first byte of the same page instead of incrementing the high half of the address to get the first byte of the next page.<p>And of course the way that an indirect threaded FORTH system works is that each word has a &quot;code field address&quot; that the FORTH inner loop jumps through indirectly. So if a word&#x27;s CFA just happened to straddle a page boundary, that word would crash!<p>6502 FORTH systems typically implemented the NEXT indirect threaded code inner interpreter efficiently by using self modifying code that patched an indirect JMP instruction on page zero whose operand was the W code field pointer. [2]<p>JMP indirect is a relatively rare instruction, and it&#x27;s quite rare that it&#x27;s triggered by normal static code (since you can usually catch the problem during testing), but self modifying code has a 1&#x2F;256 chance of triggering it!<p>A later version of the 65C02 fixed that bug. It could manifest in either compiled FORTH code, or the assembly kernel. The FIG FORTH compiler [3] worked around it at compile time by allocating an extra byte before defining a new word if its CFA would straddle a page boundary. I defined an assembler macro for compiling words in the kernel that automatically padded in the special case, but the original 6502 FIG FORTH kernel had to be &quot;checked and altered on any alteration&quot; manually.<p>[1] <a href="http:&#x2F;&#x2F;everything2.com&#x2F;title&#x2F;6502+indirect+JMP+bug" rel="nofollow">http:&#x2F;&#x2F;everything2.com&#x2F;title&#x2F;6502+indirect+JMP+bug</a><p>[2] <a href="http:&#x2F;&#x2F;forum.6502.org&#x2F;viewtopic.php?t=1619" rel="nofollow">http:&#x2F;&#x2F;forum.6502.org&#x2F;viewtopic.php?t=1619</a><p>&quot;I&#x27;m sure some of you noticed my code will break if the bytes of the word addressed by IP straddle a page boundary, but luckily that&#x27;s a direct parallel to the NMOS 6502&#x27;s buggy JMP-Indirect instruction. An effective solution can be found in Fig-Forth 6502, available in the &quot;Monitors, Assemblers, and Interpreters&quot; section here. (The issue is dealt with at compile time; there is no run-time cost. The word CREATE pre-pads the dictionary with an unused byte in the rare cases when the word about to be CREATEd would otherwise end up with a code-field straddling a page boundary.)&quot;<p>[3] <a href="http:&#x2F;&#x2F;www.dwheeler.com&#x2F;6502&#x2F;FIG6502.ASM" rel="nofollow">http:&#x2F;&#x2F;www.dwheeler.com&#x2F;6502&#x2F;FIG6502.ASM</a><p><pre><code> ; The following offset adjusts all code fields to avoid an ; address ending $XXFF. This must be checked and altered on ; any alteration , for the indirect jump at W-1 to operate ! ; .ORIGIN *+2 </code></pre> [...]<p><pre><code> .WORD DP ;) .WORD CAT ;| 6502 only. The code field .WORD CLIT ;| must not straddle page .BYTE $FD ;| boundaries .WORD EQUAL ;| .WORD ALLOT ;)</code></pre>

I once found a bug in a weather applet that only occurred when the temperature exceeded 100 degress. The 3-digit temperature caused a cascade of formatting issues that rendered part of the applet unreadable. I believe the author used Celsius, and so would never have encountered this bug on their own.

Relevant: <a href="https:&#x2F;&#x2F;gyrovague.com&#x2F;2015&#x2F;07&#x2F;29&#x2F;crashes-only-on-wednesdays&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gyrovague.com&#x2F;2015&#x2F;07&#x2F;29&#x2F;crashes-only-on-wednesdays&#x2F;</a>

&quot;tue&quot; means &quot;kill&quot; in french... I wonder if a french programmer somewhere had something to do with this?

And this is why we won&#x27;t ever get AI. Humans seem to only manage to get to a certain level of complex before it all gets too much.<p>There are supposedly people in Boeing who understand literally every part of a 747, the wiring and the funny holes in the windows. But there is probably no one who understands all parts of Windows 10.<p>We&#x27;re doomed to keep leaping like dolphins to reach a fish held too high by a sadistic Orlando world trainer

So what&#x27;s the lesson here? What should we learn from that?

Is it just me or does this get posted every month?

No, it is a cups bug indeed. File was never guaranteed to be precise in the first place, it is not a good idea to rely on it.

Yet another reason I don&#x27;t let OpenOffice or any Linux UIs slow me down. It&#x27;s all about the command line and always will be.