
“My wife has complained that OpenOffice will never print on Tuesdays” (2009) - hardmath123
https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28
======
Animats
Did this get fixed, 7 years later?

Yesterday, we had a story about Microsoft's disk management service using lots
of CPU time if the username contained "user". Microsoft's official reply was
not to do that.

I once found a bug in Coyote Systems' load balancers where, if the USER-AGENT
ended with "m", all packets were dropped. They use regular expressions for
various rules, and I suspect someone typed "\m" where they meant "\n". Vendor
denied problem, even after I submitted a test case which failed on their own
web site's load balancer.

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's sequence number
arithmetic. A combination of signed and unsigned casts was doing the wrong
thing.

~~~
btilly
My favorite was a story from the 1980s of a program which would crash
depending on the phase of the Moon!

Turned out to be because it was generating a date by calling a general purpose
astronomical routine, then parsing the date out of that. The astronomical
routine among other things included the phase of the moon, and during some
phases you would overflow the buffer that was passed in.

Another classic was a tech support call from the 1990s where the person's
computer rebooted every time they flushed the toilet. Turns out that the
person was at the end of the electrical line..and on a septic system. Flush
the toilet, the septic system came online, causing a power dip, and that was
enough to reboot the computer. A UPS fixed that.

~~~
x1798DE
> My favorite was a story from the 1980s of a program which would crash
> depending on the phase of the Moon!

Do you have a name for this program? It sounds a lot like an urban legend -
when would you ever find it easier to parse a date out of an astronomical
program than to use actual date handing capabilities from the system or a
library?

~~~
btilly
Here is a reference to a program that crashed based on the phase of the moon
for slightly different reasons: [http://www.catb.org/jargon/html/P/phase-of-
the-moon.html](http://www.catb.org/jargon/html/P/phase-of-the-moon.html)

The one that I described I first remember hearing about in undergrad. I heard
it from an astronomy student. I guess that makes it an urban legend, but a
highly believable one. In my experience inexperienced programmers are very
good at unexpectedly repurposing whatever they happen to know for new
purposes. And in an astronomy department it is easy to find inexperienced
programmers with astronomical routines at hand.

------
sampsonetics
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 _bodies_ , but the entire response was empty (not even any headers).

After a fair amount of testing, I was somehow able to determine that it wasn'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?

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 _end up_ 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.

At the time, I had looked at the code and noticed an uninitialized variable in
the response parsing function, but it didn't really hit me until much later.
The code was something like this:

    
    
      void read_status_line(char *line) {
        char c;
        while (c != '\n') {
          c = read_next_byte();
          *(line++) = c;
        }
      }
    

Obviously this is wrong because it's checking _c_ 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's _c_
variable landed smack-dab on the least-significant byte of that earlier value.
Arrrrgh!

~~~
thoman23
That sounds shockingly like a bug I remember one of our best developers
finding when I worked at Homestead in the late 90's (and I remember being in
awe then of his ability to deduce the pattern out of the seeming randomness).

------
mpeg
The title reminds me of "the 500 mile email"

[http://www.ibiblio.org/harris/500milemail.html](http://www.ibiblio.org/harris/500milemail.html)

~~~
K-Wall
This is one story I always enjoy when it is brought up.

~~~
ChristianBundy
Me too. Are there any others you could recommend?

~~~
dandelany
Some of my favorite hacker folklore:

Always Mount a Scratch Monkey
[http://edp.org/monkey.htm](http://edp.org/monkey.htm)

The Magic Switch
[https://www.cs.utah.edu/~elb/folklore/magic.html](https://www.cs.utah.edu/~elb/folklore/magic.html)

Quake3's Fast InvSqrt()
[https://www.beyond3d.com/content/articles/8/](https://www.beyond3d.com/content/articles/8/)

The Battle Chess Duck [http://blog.codinghorror.com/new-programming-
jargon/](http://blog.codinghorror.com/new-programming-jargon/) (#5)

and of course, The Story of Mel, a Real Programmer
[https://www.cs.utah.edu/~elb/folklore/mel.html](https://www.cs.utah.edu/~elb/folklore/mel.html)

edit to add: Ford and the $10,000 chalk mark (Ctrl+F Ford)
[http://www.smithsonianmag.com/history/charles-proteus-
steinm...](http://www.smithsonianmag.com/history/charles-proteus-steinmetz-
the-wizard-of-schenectady-51912022/)

~~~
marcosdumay
I just love the magic switch.

It's so obviously impossible, yet anybody that built complex hardware has seen
equally impossible things happen.

~~~
nickpsecurity
That was so fun and a great prank whether true or not. Like you, I've seen
enough oddities to think it's possible. I'm going to challenge two hardware
guys I know... one an expert on esoteric stuff. to come up with a way to make
that happen. Maybe I'll do it to a RaspPI at a maker space near MIT to screw
with them. ;)

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

~~~
linuxfan2718
only someone who doesn't understand computers would notice it, programmers
would say "that doesn't matter" :)

~~~
beambot
You'd figure it out eventually, especially if it was exceedingly annoying
and/or your job depended on it.

Example: what if your internet drops out for an hour every Sunday morning at
2am? You'd notice. (Mine does. Damn it Comcast!) If guy's wife relied on the
printer similarly, it might be as acute as losing internet for you.

------
mazda11
My most memorial bugfix was when I was on a team ,temporary ,that did email
encryption/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: "Hmm, it appears that about
1/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."

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.

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/bad ratio :)

I might remember some details wrong- but the big picture is correct :)

~~~
pwang
Respect.

I think the singular power of an experienced programmer is being able to
reason about high-level structure, while being able to deep-dive into any
lower level detail, anywhere in the overall system, and therefore be able to
carve out large swaths of problem space just by /thinking/. That's much faster
than typing-and-executing-and-reading-logs.

------
alblue
The TL;DR is that the "file" utility was miscategorising files that had "Tue"
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.

~~~
kaizensoze
The circumstances under which I discovered/reported the bug were totally
coincidental too. I noticed a friend use the file command and thought to
myself "Hmm I've never actually used that command before. Let me try it out."
Ran it on a TODO list text file I had lying around, scratched my head over the
"Erlang JAM file" output, and went from there.

------
nilstycho
The weirdest case at my tenure as a neighborhood computer tech was a personal
notebook computer that would not boot up at the customer'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.

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.

~~~
jon_richards
My car radio goes from everything working fine to complete static on every
station in like 10 feet as I drive into my local Safeway parking lot. I'm
pretty sure they are jamming the signal, I just don't know _why_.

~~~
acranox
Some places with shopping carts have an "invisible fence" that locks up one of
the wheels of the cart when you push the cart outside the property. These are
usually marked with a yellow line on the ground. I presume they use some kind
of RF field with an underground wire. Maybe that Safeway has some issues with
theirs.

------
mark-r
I have an anecdote, which isn'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'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.

------
kazinator
But "Tue" is not at the fourth byte in the example, which has:

    
    
       %%CreationDate: (Tue Mar 3 19:47:42 2009)
    

Something munged he the data. Perhaps some step which removes all characters
after %%, except those in parentheses?

    
    
       %%(Tue Mar 3 ...)
    

Now we'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:

    
    
      -+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
    

(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.

The real bug here is arguably the CUPS script. It should identify the file's
type _before_ munging it. And it shouldn'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.

Did Brother people write this? If so, I'm not surprised.

Nobody should ever write code whose correct execution depends on the "file"
utility classifying something. That is, not unless you write your own "magic"
file and use only that file; then you're taking proper ownership of the
classification logic, such that any bugs are likely to be your own.

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 _advisory_ role, not in an
_authoritative_ role.

------
Adaptive
I've noticed that printing is still one of the poorest UX aspects of *nix/OSS
and regularly seems to suffer from errors so egregious that they can only be
attributed to OSS devs not dogfooding these features. I'm assuming they just
don'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).

~~~
ultramancool
Perhaps you're thinking back to the days of manually configuring CUPS?

Any recent printer I've used has just been plug it in and hit print. A better
experience than Windows in terms of included drivers and bonjour support too.

~~~
dbcurtis
No, you've simply been lucky.

~~~
chrisfosterelli
I can say my experience matches the above posters as well. Printing in Ubuntu
works better than OSX and Windows for the 4 different printers I use
regularly.

~~~
kiwijamo
My experience with both OSX and Windows is that you just need to plug a
printer in and it just works. Can't remember that ever happening with
BSD/Linux in my experience. :( But it sounds like things have improved which
is good to know.

~~~
cyphar
In Arch Linux (and this is _Arch Linux_ ) all I ever had to do was install
avahi (explained in the docs) and CUPS would find the printers automatically.
On the other hand, I know of several cases where an OS X machine would cause
unauthenticated printers on the same network (without any printing being done
by the user) to start printing hundreds of pages of what looked like service
discovery packets.

------
carapace
Stuff like this is why I find "Synthetic Biology" so fucking scary.

~~~
Terr_
Don't worry, the natural stuff is probably just as messy, or worse.

If it helps, remember that grey-goo already took over the world, and you were
born part of it.

------
t0mek
During my studies I had a course called "Advanced Network Administration". 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.

After everything was configured I started the Quagga daemons and somehow they
just didn't want to talk to each other. I'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.

I've restarted the system to see if it's able to get up automatically, but the
problem reoccured - daemons just didn't see each other. Again, I launched
tcpdump, tweaked some settings and now it worked - until it didn't a few
minutes later.

It take me a long time to find out that diagnostic tool I'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've used the
ifconfig promisc and after that the OSPF worked stable.

[1] [http://www.nongnu.org/quagga/](http://www.nongnu.org/quagga/)

------
pif
CERN: LEP data confirm train time tables
[http://cds.cern.ch/record/1726241](http://cds.cern.ch/record/1726241)

CERN: Is the moon full? Just ask the LHC operators
[http://www.quantumdiaries.org/2012/06/07/is-the-moon-full-
ju...](http://www.quantumdiaries.org/2012/06/07/is-the-moon-full-just-ask-the-
lhc-operators/)

------
BrandonM
Near the end of that post, the commenter suggested a fix that includes the
most qualified Useless Use of Cat entry[0] that I've ever seen!

    
    
       cat | sed ... > $INPUT_TEMP
    

[0]
[http://porkmail.org/era/unix/award.html#cat](http://porkmail.org/era/unix/award.html#cat)

------
chris_wot
Wait till you see where they found the print server!

[http://www.informationweek.com/server-54-where-are-
you/d/d-i...](http://www.informationweek.com/server-54-where-are-
you/d/d-id/1010340)?

------
gchadwick
Surely the real bug is the reliance on the 'file' utility in the first place?
It attempts to quickly identify a file that could be literaly anything so it's
not surprising (and indeed should be expected) that sometimes it gets it
wrong.

I don't know the details of the CUPS script but presumably it can only deal
with a small number of different file types. Implementing it's own detection
to positively identify PS vs whatever other formats it deals with vs
everything else would be far more robust.

------
krylon
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.

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. "ABCD" became "BCDE").

I went back to the user and told her to check the little box that said "Print
text as graphics" in the PDF viewers printing dialog, and voila - the page
came out of the printer looking the way it was supposed to.

Printing that way did take longer than usual ( _a lot longer_ ), but at least
the results were correct.

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.

In a way it'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.

------
mark-r
I love the modification that pipes the output of cat into sed; doesn't he
realize that cat is redundant at that point?

~~~
adzm
I'll admit to being a superfluous cat user. I just like typing cat.

------
kinai
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.

------
gsylvie
Here's a great collection of classic bug reports (including the never-
printing-on-tuesdays):
[https://news.ycombinator.com/item?id=10309401](https://news.ycombinator.com/item?id=10309401)

------
DonHopkins
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'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!

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.

And of course the way that an indirect threaded FORTH system works is that
each word has a "code field address" that the FORTH inner loop jumps through
indirectly. So if a word's CFA just happened to straddle a page boundary, that
word would crash!

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]

JMP indirect is a relatively rare instruction, and it's quite rare that it's
triggered by normal static code (since you can usually catch the problem
during testing), but self modifying code has a 1/256 chance of triggering it!

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 "checked and altered on
any alteration" manually.

[1]
[http://everything2.com/title/6502+indirect+JMP+bug](http://everything2.com/title/6502+indirect+JMP+bug)

[2]
[http://forum.6502.org/viewtopic.php?t=1619](http://forum.6502.org/viewtopic.php?t=1619)

"I'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's a direct parallel
to the NMOS 6502's buggy JMP-Indirect instruction. An effective solution can
be found in Fig-Forth 6502, available in the "Monitors, Assemblers, and
Interpreters" 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.)"

[3]
[http://www.dwheeler.com/6502/FIG6502.ASM](http://www.dwheeler.com/6502/FIG6502.ASM)

    
    
        ;    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
    

[...]

    
    
                  .WORD DP       ;)
                  .WORD CAT      ;| 6502 only. The code field
                  .WORD CLIT     ;| must not straddle page
                  .BYTE $FD      ;| boundaries
                  .WORD EQUAL    ;|
                  .WORD ALLOT    ;)

~~~
nickpsecurity
I vote this as the best heisenbug I've read so far. That's sounds like such a
nightmare to debug. I might have never found it due to throwing the thing in
the trash and buying a different machine. Forth is easy to port after all. :)

------
rcthompson
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.

------
jpatokal
Relevant: [https://gyrovague.com/2015/07/29/crashes-only-on-
wednesdays/](https://gyrovague.com/2015/07/29/crashes-only-on-wednesdays/)

------
GigabyteCoin
"tue" means "kill" in french... I wonder if a french programmer somewhere had
something to do with this?

------
lifeisstillgood
And this is why we won't ever get AI. Humans seem to only manage to get to a
certain level of complex before it all gets too much.

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.

We're doomed to keep leaping like dolphins to reach a fish held too high by a
sadistic Orlando world trainer

~~~
dilemma
As I've said and been downvoted for before, there will never be Artificial
Intelligence because a machine merely does what its program tells it. There
will be plenty of Artificial Stupidity, however, as evidenced by this thread.

~~~
21
And you do what the neurons in your brain make you do.

Article from today -
[http://www.theatlantic.com/magazine/archive/2016/06/theres-n...](http://www.theatlantic.com/magazine/archive/2016/06/theres-
no-such-thing-as-free-will/480750/)

~~~
mark-r
You might be interested in what Scott Adams (the Dilbert cartoonist) has to
say about the current presidential election:
[http://blog.dilbert.com/](http://blog.dilbert.com/)

------
gregschlom
So what's the lesson here? What should we learn from that?

~~~
kaizensoze
Make sure you escape spaces? Or:
[https://news.ycombinator.com/item?id=11718716](https://news.ycombinator.com/item?id=11718716)

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

~~~
jon-wood
I've never seen it before to my recollection, and I spend a possibly unhealthy
amount of time checking up on the stories here, so my guess is no it doesn't.

~~~
broodbucket
It was a rhetorical question that was incorrect. Every month is a little bit
too frequent, but not by much...

[https://hn.algolia.com/?query=openoffice%20tuesday](https://hn.algolia.com/?query=openoffice%20tuesday)

Probably because it gets mentioned often in addition to be reposted often.

------
sklogic
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.

------
meeper16
Yet another reason I don't let OpenOffice or any Linux UIs slow me down. It's
all about the command line and always will be.

~~~
Spivak
> So it's not a problem w/ openoffice.org, cups, or the brother printer
> drivers. It is a bug in the `file` utility, and documented at
> [https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619](https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619).

This bug had nothing to do with OO. This was just a cute manifestation of the
actual bug.

