I would guess the gif triggers a specific edge case that would crash, and grammarly is just a common enough addition to chrome with a lot of edge case triggers that it was identified. I’d guess this is on the Chrome team to fix soon, but yeah, at least post the spinner file for us!
I‘d guess it’s because Grammarly enables full accessibility support in Chrome to be able to access the browser elements similar to e.g. a screen reader. This is off by default and has caused me various issues in the past when enabled (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=136448... ). However it’s probably good that the Accessibility functions get more exposure due to this.
Well, this is a fascinating murder mystery that establishes 3 compelling suspects - Grammarly, Chrome, and a gif - and then just ... ends, right before the big reveal.
I have a friend who worked at Gusto, and my wife tried using Gusto for her small business (they handle payroll for small business, got a big boost from the pandemic). The lack of technical resolution here is so Gusto, it hurts.
That's unfair: isn't this is exactly how most strange bugs get "fixed" by most companies?
It is an abnormal developer and an even more abnormal business that actually spends enough time to find the root cause of outré glitches. Especially when you start having to debug complex third party systems to debug them properly - requires skills and motivation plus a company that will encourage a developer to do that.
The story is not specific to Gusto - it is the story of every developers life. I have chased down bugs in my OS and my browser - it is rarely well rewarded! Fixing a compiler bug should be on my bucket list! A long time ago I worked around a compiler bug by inserting a label: (I think the label prevented certain optimisations where the label was put).
I mean, this story is a hell of a rundown of debugging. The fact they don't have insight into the ways Chrome or Grammarly work isn't something to apologize for.
Maybe it’s because Grammarly enables full accessibility support in Chrome to be able to access all elements in the browser (similar to a screen reader). This has caused me various issues in the past (e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=136448... ). However it’s probably good that the Accessibility functions get more exposure due to this.
The GIF cannot be responsible: as untrusted web content, if it can trigger a crash, the responsibility lies with the local software stack. So you have only two suspects: Chrome and Grammarly. The GIF is at most an accomplice.
I wouldn't even know how to look for something unusual in a gif's source code but I also feel this is the most compelling part. I wish they'd uploaded it.
> I wouldn't even know how to look for something unusual in a gif's source code but I also feel this is the most compelling part. I wish they'd uploaded it.
GIF stands out as a widely understood file format [1][2].
To kick things off, delve into the GIF file using a hexadecimal editor. HexFiend [3], for instance, offers a template for visualizing GIF file structures [4]. Another excellent option is Synalyze It! [5], which comes pre-loaded with an extensive list of file formats, encompassing GIF among others.
These visualizations serve as a guide to pinpoint any irregular byte clusters that might pose issues when loading the file into an application with an image reader lacking support for that specific byte group or its arrangement. Once you've identified such a cluster, consider it the bug.
Kaitai Struct[1] is my preferred tool for parsing binary files. It's open-source (unlike Synalize It! and 010 Editor) and cross-platform (unlike HexFiend). Not sure how it compares to ImHex's pattern language, though—I've been put off by ImHex's UI the few times I've tried it.
My favorite thing about the Kaitai Web IDE is that it instantly updates the parsed tree as you make changes to the format specification, which makes it viable for reversing unknown formats instead of just specifying known ones.
I wonder what version of Chromium they used. If it was a nightly, it could be weeks before the fix makes it into Chrome. They might've tested at a time when latest Chrome had the bug and Chromium didn't.
I wish this was upvoted more. This is the correct way to troubleshoot the bug, full stop. You can get symbolic stack traces with full arguments and source code on Windows in about 5-10 minutes for any Chrome crash by following these instructions. I always have a last change exception handler that fires up a WinDBG script on Windows for our chromium-based test runners, which reduces troubleshooting time to just a couple minutes in order to find the symbol in their bug database. Playing blackbox what-if games like the Gusto team is a waste of time and doesn't contribute any situation-specific knowledge to bugs.chromium.org.
I am using chromium to print web pages to pdf, and I have some images that will crash chrome's to pdf process, I found nothing wrong with this images, the metadata is fine (nothing weird in it). The other bad thing it does not reproduce n my dev machine only on the production server , so nothing I can do, in rare cases an image will always crash crhomium, I find it, open it and re-export it and then it works.
This sounds more like a hardware fault than something wrong with the software, especially since it doesn't seem to be deterministic.
But stranger things have happened, and given the enormous surface area of a modern computer (hardware, software, drivers, state, etc.) can anything truly be deterministic?
It happens with that image no matter what. I can have a html with 100 images and one bad image, I make one new html only with that image and it still has the problem. My guess is that probably a bug in a low level image decoder. My local machine has different kernel, different libs, plus I have different cpu,gpu and X11 on top so too much difference and I do not have the expertese to do aremote debug(or local)
Discord suffered (suffers?) from a similar thing with gifs. It is or was common for people to post specifically crafted gifs in channels, anyone viewing the channel immediately had their client crash.
Discord client uses Electron, which is in turn Chromium.
Seems like they're posting it because it was a fun story, and it's free advertising - this wasn't externally visible so I don't see where fault comes into it.
Yes, I too would like to read more details about this. It's a great writeup from an engineer who got stuck debugging this. But I hope some experts in security or reverse-engineering can replicate it and take a closer look. There's definitely a more interesting story here, probably regarding the localhost bridge between Grammarly extension and desktop.
(Grammarly has a bug bounty btw... and their chrome extension has quite a large surface area...)
If OP is here: can you provide the raw .gif file? (And if you're feeling generous, maybe even a minimal ruby example that replicates that templating setup, although it sounds like that wasn't required to reproduce it in the end.)
P.S. "For security reasons, we do not have Chrome crash reporting enabled" - maybe consider disabling Grammarly extension for the same reasons ;)
I guess I just assumed the extension was installed too, and communicating with the desktop app. But now I see the post doesn't mention the extension. If it was triggered even without the presence of the extension then that's quite strange, and even more suspicious - is that gif triggering a call to a localhost endpoint? Is the grammarly desktop app interacting with browser elements without using the extension? (IIRC the grammarly app uses some accessibility privileges to inject into textareas across all apps)
Grammarly is honestly insane, I can't believe corporations allow it to run on employee machines.
> Is the grammarly desktop app interacting with browser elements without using the extension? (IIRC the grammarly app uses some accessibility privileges to inject into textareas across all apps)
It seems like that must be the case. If we have the details right about desktop app only (which seemed pretty clear).
A disappointing ending to the tale. I really want to know how Grammarly desktop works now. It must have interfered with the Chrome process in some bad way.
I didn't mean literally fix the underlying bug. They also don't really know why their workaround worked, which means it could not really be fixed at all.
Someone once said, there is accidental function, and deliberate function.
If your system doesn't work, and you just plonk around at values, until, very surprisingly, the system starts behaving well and you the call it working... well it might be working now. But it's just accidental correctness. As soon as something causes the system to bank left, something's gonna break and no one knows how to fix it - and you're back to square one.
On the other hand, as hard as it is, if you can clearly tell why your fix will restore function to the system without even applying it, you have deliberate correctness and function. If done right, it is very boring, because exactly and only the expected thing will happen. You should know about the unknowns and plan around those as well, so even if an unknown bites you, it's a known and handled unknown. This can be exhausting to make happen, because it is much harder, but those systems will just work.
But this is a fight I have with some development teams probably forever. "But we poked at the values, and that stopped the flames. It is fixed!" "but why?" "Dunny. But no fire anymore. All good." And then 2 weeks pass, and there is more fire and everyone is like "Oh but why would this happen? How should we have known for this to happen again"
On the other hand, I've spent weeks with a team looking for a bug, and by the time we found something that appeared to fix it, we were way behind on everything else that really needed to get done. How long would it take to find the root cause? We tried. It wasn't worth weeks or months of effort, to anyone. This isn't JPL and human lives weren't on the line. We just needed it not to crash so we could all get on with the "real" task of shipping useful and profitable software.
Yeah, that is why software engineering and system operations is hard.
For example, the article doesn't get to a root cause in an absolute way. There is no absolute SEGFAULT of the OS causing the misbehavior. However, they nail down the crash to a gif, and if the gif is in, it crashes, and if the gif is out it doesn't. If the gif is loaded otherwise it crashes, too. At that level, to me, that would be enough, because we're users of the browser's rendering there.
Finding a solid cause that can demonstrate and reproduce a problem, and basing a workaround around that at a boundary you're unwilling to cross can be fine. If it's within the company, it absolutely is fine as long as you escalate beyond that boundary.
However, I have enough teams who are like "Oh, we set all values to 25 one by one and when we arrived at flum-value at 25 it stopped crashing. Fixed." Why 25? Who knows. Why flum? Who knows. Maybe the other value changed at the same time fixed it? Who knows. Do we use 26 once it starts crashing again? Fuck knows. Maybe 24 is better?
We have no explanation for 25, so why would 25 be a good fix?
And in fact, I don't think they have fixed it. I've seen "Error 5" plenty of times in Chrome. It seemingly occurs whenever I have a lot (100+) of tabs open for any site where each page allocates at least one accelerated drawing canvas (a literal <canvas>, or a <video>, or a .gif <img>.) I've seen it happen on Reddit (but only new reddit, not old reddit!) and on a number of other sites.
I hypothesize that Chrome simply has a global (i.e. cross-tab) per-toplevel-origin limit to the number of allocated accelerated drawing canvases it's willing to allow; and that when you go over it, Chrome forcibly de-allocates all the existing drawing canvases used by other tabs that have that toplevel origin loaded, thereby causing them to crash. It's probably a measure designed to prevent a site from from DoSing your computer by just allocating an infinite number of canvases.
It doesn't have to be tons of open tabs; it can just as well be one tab that makes tons of accel draw contexts all on its own — maybe temporary hidden <canvas> draw contexts that it never cleans up. But a dev would usually end up hitting that kind of problem during development; whereas, if the problem never arises through "normal use" but instead requires having 100+ open tabs on the site to trigger, that bug might go unnoticed all throughout the QA process.
I can also extend my speculation about all the times I've personally seen "Error 5", although this is probably dipping into superstition territory: I think the per-toplevel-origin draw-context limit isn't static, but is influenced by the amount of VRAM available on the computer as a whole.
So on an extremely VRAM-constrained system like a Raspberry Pi (or on a system that's running Cyberpunk 2077 on one display and Chrome on another, sharing a GPU) the per-toplevel-origin limit on accel draw contexts might be dropped as low as, say, 5: an amount low enough that just having one extra .gif on the single tab of the site you have open might be enough to make the tab fall over.
I agree 100% and the observe this all the time with things that “magically fix themselves.” But Im not sure it applies here since they seemed to have actually quarantined it.
I suppose since they dont know the root cause it’s impossible to say. But I think the saying would fit better if they kept the gif but made some change that seemed to fix it without knowing why.
No, they didn't. They figured out a workaround. Since they didn't find the root cause of the problem themselves and apparently didn't take it up with the Chrome or Grammarly development teams, they don't actually know what happened or when it might bite their customers again.
They say it no longer reproduces on current Chrome/Grammarly, so taking it up with them is fruitless. They're not going to investigate crashers from old versions.
:( I would've tried to determine the cause of the crash with that specific file in my off time, provided that I could isolate the code in the Grammarly extension in Chrome.
The main reason –other than curiousity– is to ensure that a future regression (in Chrome/Grammarly) wouldn't lead to it again.
The weirdest one I saw was this: User claims that the wording of the info they enter into a certain form changes when they save. At first I suspected someone else editing the same form at the same time unbeknownst to each other but it wasn't the case according to the logs. And I saw the correct wording on my own computer.
Then I noticed in their screenshots that some of the menus had weird wording too. Turns out they had Chrome's "Translate this page" option on. Problem went away when we showed them how to properly switch languages in the app.
to all pages in a single-page-web-app after discovering some bug or other with Chrome screwing up the page.
Apparently the new incantation to fix an app (can be applied to an element) is (ugly: I presume it isn't CSS to avoid supporting dynamically changing it):
Every now and then I would look at the meta tags for a major single page app and discover some new horror when searching for the reason for the meta tag!
Good point. This was the Elizabethan days when computers ran on coal: IE when we were explorers of The Internet.
We were bleeders, but there still existed a vestigial login page, and some other evil cthulic pages (I know whence they were begat for I was their father).
In Norway, the word “subject” translates to “fag”. Back in the Usenet days there was a Norwegian group or hierarchy named “no.fag”, which of course regularly got misunderstood.
This is really annoying. I often rely on Google Translate to read Japanese websites (I can read Japanese but only very slowly), and it breaks every website using React [1] because both React and Google Translate try to update DOM nodes without knowing each other. I even seriously looked at Google Translate to see how they are implemented, so that maybe I can recreate the web widget without this issue in the future.
Did they open a bug against Chrome with the image file? I feel like any crash on user-provided data is a big deal, always a correctness problem, but potentially a security problem. "We deleted the image so the problem is fixed for us" is OK (I wouldn't waste time writing a blog post about it personally), but I think that Chrome needs to fix this bug.
That doesnt hold when you consider they opened the gif in the browser with and without grammarly and it only crashed with. So its not simply a bad gif and chrome.
Does Grammerly hook something in Chrome? If not, then it's still probably a Chrome bug, even if some second-order effect of Grammerly is necessary to trigger it.
It looks like the desktop Grammerly app hooks into all sorts of things, "An all-in-one writing assistant that works on your desktop and in your browser. Use it in apps, word processors, email clients, and more."
The pr seems to suggest it's not the filename though given the new file was named the same and didn't crash.
I would guess grammarly is hooking chrome and potentially trying to read metadata about images, and the particular gif had metadata in a format they hadn't expected.
While something like that is worth a shot, the PR they shared showed the file as being ‘assets/images/loader-spinner.gif’. If the file name was the cause that bug would be everywhere.
Reminds me of the story I read where the guy's car wouldn't start depending on what flavor of ice cream he picked and when investigated he was right. Some kind of evaporation/vacuum leak or something that was dependent on time and some flavors were farther away in the store and took more time to buy.
A friend of mine had an aunt who passed away, and so he ended up inheriting her car. The car came with a petrified apple pie in the back. He was insistent that the car would not start without the pie in the back window.
Several of his friends who he played in a punk band with confirmed this, that they had tested it. Take the pie out, car won't start. Put the pie back in, the car starts.
I don't think anyone ever figured out what was going on, I graduated a couple of months after hearing the story, and fell out of touch. But - timing and vapor lock makes sense, if they were always testing it by first starting the car, removing the pie, and then putting the pie back in.
As an aside, the aunt who had passed away was one Aunt Martha (after which the car was also named), which in honor of the strange car and its strange pie was what their garage punk band was named after. There's some totally unrelated band now called Aunt Martha - any evidence of their band is not on the internet.
The Snopes page doesn't really seem to debunk it, but merely points out that the legend's been retold with many variations and contradictory explanations. Suspicious, definitely, but it doesn't seem clear that none of the variations could ever have happened?
Sorry, but no. The null hypothesis is that there is no relation between two variables. You have to do experiments to estimate the probabilities of the null and alternative hypotheses. You don't get to label the one with the higher prior as the null hypothesis; that's simply not what that term means. It does indeed mean "it's not true [that A affects B]".
> If my wife said "I'm going to the shops" I wouldn't assume she was lying until proven otherwise.
I certainly hope you wouldn't! But the null hypothesis would indeed be that the words she speaks have no bearing on whether she is going shopping. I don't know your wife, but I find it easy to believe that your prior probability of that hypothesis is quite low.
(At least, until it becomes a pattern where she's regularly staying out all night with more and more flimsy excuses....)
Yeah, that would have been a good first step, but he does admit to not really knowing much about browsers:
> This was fairly far outside the usual scope of our on-call issues. Our team is generally well-insulated by other teams from issues like browser compatibility, so I didn’t know the first thing about browser debugging.
Why would they disable crash reporting for security reasons (which might actually help solve the root cause of their availability problem, which they never did solve)... yet run Grammarly (which I'd guess, security-wise, is less trustworthy than Google, in how they secure data themselves once they've inevitably stolen it from the customer)?
This reminds me of similar issues I've encountered as a software engineer. I first ran into this issue about a decade ago, albeit not because of Grammerly,but due to some specific gif causing web app to crash. Both times the gifs were animated. Happened years apart and at different companies.
I see some comments highlighting RAM, which could totally have been the issue. Totally looking forward to a follow up to this later down the road, I am sure this isn't going to be the last time we hear of this.
333 comments
[ 4.5 ms ] story [ 280 ms ] threadI have absolutely no idea how a combination of grammarly and a specific gif would cause a browser crash though…
Anyone here use the grammarly desktop app? Any additional clues?
The customer response team was extremely quick and responsive telling me their hands were tied.
Fuck Gusto.
“Sorry, the system says no”
Had similar situations with PayPal and Uber recently where their support have absolutely no information or ability to take a decision.
Support essentially becomes a glorified text-to-speech system.
It is an abnormal developer and an even more abnormal business that actually spends enough time to find the root cause of outré glitches. Especially when you start having to debug complex third party systems to debug them properly - requires skills and motivation plus a company that will encourage a developer to do that.
The story is not specific to Gusto - it is the story of every developers life. I have chased down bugs in my OS and my browser - it is rarely well rewarded! Fixing a compiler bug should be on my bucket list! A long time ago I worked around a compiler bug by inserting a label: (I think the label prevented certain optimisations where the label was put).
GIF stands out as a widely understood file format [1][2].
To kick things off, delve into the GIF file using a hexadecimal editor. HexFiend [3], for instance, offers a template for visualizing GIF file structures [4]. Another excellent option is Synalyze It! [5], which comes pre-loaded with an extensive list of file formats, encompassing GIF among others.
These visualizations serve as a guide to pinpoint any irregular byte clusters that might pose issues when loading the file into an application with an image reader lacking support for that specific byte group or its arrangement. Once you've identified such a cluster, consider it the bug.
[1] https://en.wikipedia.org/wiki/GIF#Example_GIF_file
[2] https://www.w3.org/Graphics/GIF/spec-gif89a.txt
[3] http://hexfiend.com
[4] https://github.com/HexFiend/HexFiend/blob/master/templates/I...
[5] https://www.synalysis.net
https://github.com/WerWolv/ImHex
My favorite thing about the Kaitai Web IDE is that it instantly updates the parsed tree as you make changes to the format specification, which makes it viable for reversing unknown formats instead of just specifying known ones.
[1] https://ide.kaitai.io/
> We also confirmed with many of our affected users that they had Grammarly installed on their computers.
Ironic.
I mean, you basically do! You can just go check out the chromium source.
It's mentioned in the bullet points in the "trouble reproducing the bug" section that chromium wasn't affected.
> Using open-source Chromium instead of Chrome did not cause crashes, so we couldn’t see what Chrome code was failing either.
But stranger things have happened, and given the enormous surface area of a modern computer (hardware, software, drivers, state, etc.) can anything truly be deterministic?
Discord client uses Electron, which is in turn Chromium.
Also, I am fully here for Gusto posting this to say "wasn't our fault" and to throw some shade at Grammarly in the process
(Grammarly has a bug bounty btw... and their chrome extension has quite a large surface area...)
If OP is here: can you provide the raw .gif file? (And if you're feeling generous, maybe even a minimal ruby example that replicates that templating setup, although it sounds like that wasn't required to reproduce it in the end.)
P.S. "For security reasons, we do not have Chrome crash reporting enabled" - maybe consider disabling Grammarly extension for the same reasons ;)
Grammarly is honestly insane, I can't believe corporations allow it to run on employee machines.
It seems like that must be the case. If we have the details right about desktop app only (which seemed pretty clear).
The Larvae of leafhoppers are commonly known as spittlebugs, which create protective bubble nests while feeding on plant stems
If you don't know why the fix worked, you may not have actually fixed it.
The best they could do was work around it.
Sometimes workarounds are the best you can do until your vendor provides a real fix.
If your system doesn't work, and you just plonk around at values, until, very surprisingly, the system starts behaving well and you the call it working... well it might be working now. But it's just accidental correctness. As soon as something causes the system to bank left, something's gonna break and no one knows how to fix it - and you're back to square one.
On the other hand, as hard as it is, if you can clearly tell why your fix will restore function to the system without even applying it, you have deliberate correctness and function. If done right, it is very boring, because exactly and only the expected thing will happen. You should know about the unknowns and plan around those as well, so even if an unknown bites you, it's a known and handled unknown. This can be exhausting to make happen, because it is much harder, but those systems will just work.
But this is a fight I have with some development teams probably forever. "But we poked at the values, and that stopped the flames. It is fixed!" "but why?" "Dunny. But no fire anymore. All good." And then 2 weeks pass, and there is more fire and everyone is like "Oh but why would this happen? How should we have known for this to happen again"
For example, the article doesn't get to a root cause in an absolute way. There is no absolute SEGFAULT of the OS causing the misbehavior. However, they nail down the crash to a gif, and if the gif is in, it crashes, and if the gif is out it doesn't. If the gif is loaded otherwise it crashes, too. At that level, to me, that would be enough, because we're users of the browser's rendering there.
Finding a solid cause that can demonstrate and reproduce a problem, and basing a workaround around that at a boundary you're unwilling to cross can be fine. If it's within the company, it absolutely is fine as long as you escalate beyond that boundary.
However, I have enough teams who are like "Oh, we set all values to 25 one by one and when we arrived at flum-value at 25 it stopped crashing. Fixed." Why 25? Who knows. Why flum? Who knows. Maybe the other value changed at the same time fixed it? Who knows. Do we use 26 once it starts crashing again? Fuck knows. Maybe 24 is better?
We have no explanation for 25, so why would 25 be a good fix?
I hypothesize that Chrome simply has a global (i.e. cross-tab) per-toplevel-origin limit to the number of allocated accelerated drawing canvases it's willing to allow; and that when you go over it, Chrome forcibly de-allocates all the existing drawing canvases used by other tabs that have that toplevel origin loaded, thereby causing them to crash. It's probably a measure designed to prevent a site from from DoSing your computer by just allocating an infinite number of canvases.
I can also extend my speculation about all the times I've personally seen "Error 5", although this is probably dipping into superstition territory: I think the per-toplevel-origin draw-context limit isn't static, but is influenced by the amount of VRAM available on the computer as a whole.
So on an extremely VRAM-constrained system like a Raspberry Pi (or on a system that's running Cyberpunk 2077 on one display and Chrome on another, sharing a GPU) the per-toplevel-origin limit on accel draw contexts might be dropped as low as, say, 5: an amount low enough that just having one extra .gif on the single tab of the site you have open might be enough to make the tab fall over.
I suppose since they dont know the root cause it’s impossible to say. But I think the saying would fit better if they kept the gif but made some change that seemed to fix it without knowing why.
I guess some things never change.
The main reason –other than curiousity– is to ensure that a future regression (in Chrome/Grammarly) wouldn't lead to it again.
Then I noticed in their screenshots that some of the menus had weird wording too. Turns out they had Chrome's "Translate this page" option on. Problem went away when we showed them how to properly switch languages in the app.
Apparently the new incantation to fix an app (can be applied to an element) is (ugly: I presume it isn't CSS to avoid supporting dynamically changing it):
https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...Every now and then I would look at the meta tags for a major single page app and discover some new horror when searching for the reason for the meta tag!
> all pages in a single-page-web-app
We were bleeders, but there still existed a vestigial login page, and some other evil cthulic pages (I know whence they were begat for I was their father).
https://www.eia.gov/energyexplained/electricity/electricity-...
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=872770
it's hilarious
I wish they tried to simply rename the file instead of remove it.
I would guess grammarly is hooking chrome and potentially trying to read metadata about images, and the particular gif had metadata in a format they hadn't expected.
A friend of mine had an aunt who passed away, and so he ended up inheriting her car. The car came with a petrified apple pie in the back. He was insistent that the car would not start without the pie in the back window.
Several of his friends who he played in a punk band with confirmed this, that they had tested it. Take the pie out, car won't start. Put the pie back in, the car starts.
I don't think anyone ever figured out what was going on, I graduated a couple of months after hearing the story, and fell out of touch. But - timing and vapor lock makes sense, if they were always testing it by first starting the car, removing the pie, and then putting the pie back in.
As an aside, the aunt who had passed away was one Aunt Martha (after which the car was also named), which in honor of the strange car and its strange pie was what their garage punk band was named after. There's some totally unrelated band now called Aunt Martha - any evidence of their band is not on the internet.
https://web.mit.edu/jemorris/humor/500-miles
Not to be blunt, but you might get a closer shave with Occam's Razor.
If my wife said "I'm going to the shops" I wouldn't assume she was lying until proven otherwise.
> If my wife said "I'm going to the shops" I wouldn't assume she was lying until proven otherwise.
I certainly hope you wouldn't! But the null hypothesis would indeed be that the words she speaks have no bearing on whether she is going shopping. I don't know your wife, but I find it easy to believe that your prior probability of that hypothesis is quite low.
(At least, until it becomes a pattern where she's regularly staying out all night with more and more flimsy excuses....)
Never do you see the guy investigating memory usage, which is weird.
> This was fairly far outside the usual scope of our on-call issues. Our team is generally well-insulated by other teams from issues like browser compatibility, so I didn’t know the first thing about browser debugging.
For another fun debugging tale, google: Mazda radio Seattle NPR bug
I see some comments highlighting RAM, which could totally have been the issue. Totally looking forward to a follow up to this later down the road, I am sure this isn't going to be the last time we hear of this.