Remember the jokes (OK, they were sold as “jokes” when you were at school to add a touch of excitement to Eng. Lang. lessons) about creating valid and allegedly meaningful sentences with a single word repeated many times?
There’s an very dubious one with the word BUFFALO seven times in a row, which relies on the various meanings Buffalo-the-placename, referring to the riverside city in New York State; buffalo-the-bovine-beast, also known as a bison; and buffalo-the-metaphorical-verb meaning “to bully or intimidate.”
There’s a slightly less bizarre sentence with HAD repeated a whopping 11 times, which imagines a Latin grammar lesson in which pupils are asked to compare the ancient Roman perfect tense, often translated with “had”, and the pluperfect, commonly translated as “had had”.
But the best known, and perhaps the most believable, is five ANDs in a row, a sentence helped by the fact that AND is a conjuction, so with a suitable comma you can insert it between almost any two English sentences and produce a legal compound clause.
Thus the famous complaint by the innkeeper who’s just had their pub sign repainted badly, and disappointedly tells the signwriter, “You didn’t leave enough space between ROSE and AND, and AND and CROWN.”
Well, in an amusing start to the weekend, Google Docs has apparently just fixed a five-ANDs-in-a-row crisis in its online, real-time grammar checker.
Apparently, until Google quickly fixed the problem earlier today, entering five ANDs in a row was considered a sufficiently grievous conjunctional blunder that entering such a sequence into your browser…
…would instantly crash Google Docs.
Recursion: see Recursion
To be slightly more precise, it seems that the bug only appeared if you had grammar checking turned on.
If you never had it on, or if you had had it on (we couldn’t resist trying out a pluperfect there) but later turned it off, you’d be OK.
Also, the ROSE AND CROWN sentence above wouldn’t do it, because you had to commit the solecism of using AND in a sentence all of its own five times in a row, with a leading capital letter each time, like this:
And. And. And. And. And.
What happened?
The original reporter uncovered a curious but inconclusive error message in the background that said, TypeError: Cannot read properties of null (reading 'C'). (No, we don’t know what sort of ‘C’ that refers to.)
We’re guessing that some of recursive grammatical parsing function hit some untested internal limit, such as unexpectedly running out of input data, not having enough storage space left over to carry on its anlysis, or blundering into a dead-end street in some convoluted grammatical state machine.
The internet (especially the weekend-is-coming-soon-internet) being what it is, keen Google Docs users promptly set out to find other grammatical constructs that might also trigger the bug, quickly finding that other conjunctions, if used unexpectedly in five consecutive solo sentences, would do the trick.
The words ANYWAY, BESIDES, BUT, HOWEVER, THEREFORE, WHO and WHY were quickly added to the trigger-list, but human-based guessing wasn’t enough for one Ycombinator user, who decided that a problem this obscure deserved more extensive and automated research.
Hacker News contributor JoshuaDavid wrote that they “started running through the entire dictionary in batches of 500 words to see if each batch of 500 triggered the behaviour, then binary search[ed] within the batch to find the problem word(s). Got bored partway through D.”
Binary search is where you split an ordered list in half, and see if the answer you are looking for would be in the top or the bottom part, like a precisely co-ordinated TV-show game of Higher! Lower! You then discard the half it couldn’t be in, and repeat the procedure recursively with the remaining half of the list, thus pruning the search space logarithmically rather than linearly. Eventually, either you hit upon the answer in the list, or you end up with just one item left that doesn’t match, so you know the answer isn’t there. You can search an ordered list of, say, 16 million items this way in just 24 tries, because you only need to divide 16M in half 24 times before you are down to a single item. That’s because 224 = 16,777,216 and, equivalently, log216M = 24.
Bored. Unbored.
Fortunately, JoshuaD reports that they soon became “unbored”, and decided to start where they left off, resuming their dictionary bisection project at the letter E.
Intriguingly, they found that the numerical adverbs FIRSTLY, SECONDLY, THIRDLY and FOURTHLY all caused the document crashing problem, but not the adverbs of any higher numbers, such as FIFTHLY or FOURTEENTHLY, which is admittedly not a word you need to use very often.
What to do?
Google hasn’t yet said what caused the bizarre bug, but it did quickly say it was “working on a fix”, and reports suggest that the fix is already in.
We’re don’t use Google Docs ourselves, and we tend to turn grammar checkers off because we find that today’s “writing assistants” seem happiest when everyone writes in the same, predictable way, which feels dull to us…
…so we don’t know whether you need to take any special measures if you have any genuine documents that were victims of this crash before it was patched.
Internet commenters proposed various workarounds while the bug was still in play, including opening buggy documents on your mobile phone (where the problem didn’t show up) in order to edit out the crashtastic text, thus making the file safe again to open in your browser.
Other “fixes” were to turn off grammar checking, create at least one new document, then open the ones that you couldn’t open before without re-crashing the document.
We’re assuming, now that the bug is fixed or at least suppressed in Google’s cloud code, that you can simply re-open crashy documents and carry on where you left off.
Oh, and if you hear what actually happened, please let us know in the comments… we suspect that the backstory will be a fascinating tale!