The weirdest bug I've seen yet
engineering.gusto.comAs I was reading this I was thinking to myself "I wonder if it is grammarly related" because I experienced a bug some time ago that presented itself in a similar way. It was impossible to reproduce but affecting lots of people internally within certain departments. Eventually we figured out the thing they had in common was that they had the Grammarly extension installed.
The other key thing was that the bug only appeared on our staging preview urls, not on the live website. It turned out it was because of a bad regex in the grammarly extension that caused the page to hang if the domain name was more than about 100 characters. Our staging domains were pretty long, I think they contained a few subdomains and had a job number or something in there.
This one is more crazy though if it is really caused by the desktop app - that's pretty scary!
I was so disappointed that the story ended with we can't look inside Grammerly or Chrome to know why the gif decode/rendering causes it to crash. This isn't interesting at all. Many problems get narrowed down to some combination but not knowing really why is unsatisfying.
It would be nice if the author would at least publish the .gif file. I want to dig into this.
Second this. Also, I'd like to know what was different in the new gif.
Agreed. I was on the edge of my seat. I wouldn’t do a write up for something like this. I feel no-soap radio’d.
TIL: Thanks for that. https://en.wikipedia.org/wiki/No_soap_radio
The Chromium source code is also available, not sure why they said they couldn't look at it. If it replicates with Chromium you can dig right in.
If you read carefully you will see that they said the bug didn’t replicate with Chromium
They did yeah, but did they try Chromium with Grammarly?
They say it didn't replicate in Chromium but that's before they figured out what it was.
> It turned out it was because of a bad regex in the grammarly extension that caused the page to hang if the domain name was more than about 100 characters.
Just today I debugged a regex that would DoS our backend whenever the user enters the wrong thing in a form.
Now I'm reading up on regex engines: https://swtch.com/%7Ersc/regexp/regexp1.html
Just in case you haven't seen the postmortem of the Cloudflare outage which also was caused by a regex based DoS: https://blog.cloudflare.com/details-of-the-cloudflare-outage...
That was a great read, but there was one thing I didn't understand: Why would the regex string have "." twice in a row? What does ".." find that "." doesn't find? Does that just mean "at least two characters"?
It means specifically 2 characters, and is equivalent to .{2}
..+ or ...* are ways of writing "at least two characters".
A single `.` matches exactly one character. `..` matches exactly two characters (not more, not less).
I had a ReDoS issue at a prior company many years ago; at least they're lintable now:
https://ota-meshi.github.io/eslint-plugin-regexp/rules/no-super-linear-move.html https://www.npmjs.com/package/eslint-plugin-redos/v/1.2.0
Holy shit. I had a similar thing happen with some web based video surveillance software maybe 5 years ago.
A manager of some sort had his aging laptop replaced due to a company wide Windows 10 upgrade project. Super friendly older guy, probably in sales. IT went through all the procedures of inventorying software and network needs, backing up user profile and docs, etc. Great processes in place. I remember this because I saw the device assessment and it was like a 10 year old Thinkpad with 4G of RAM and a note saying he had to keep it plugged in at all times or it would shut down. Who puts up with that? Patience of a saint. Anyway.
Laptop was deployed by onsite IT to verify everything was gravy. All checked out except for Grammarly. License didn't get transferred properly or something so they had to put in a request to get his licensing working.
Fast forward a week and he gets his license key and Grammarly is tested good to go. He's checked off the list.
Later that day we get a call about not being able to see security cameras because the web page is crashing. Helpdesk tries the basics, reboot, clear cache, reinstall browser, rebuild profile, etc., nothing works and it gets escalated to me. I check the network, firewall logs, log into another PC, onsite, off-site, etc. All working for me, no one else having issues.
I tell him "I'm completely baffled here, have there been any changes lately? In your office? With your PC?" He jokingly says "Well yeah they installed Grammarly today maybe that's it?" We both laugh and I say well, I'm literally out of ideas, fuck it let's try it.
I remote in and uninstall Grammarly. "Ok go ahead and try the cameras lol". I then watch him open up Outlook, go to a folder named "Cameras", and open an email with a link to his cameras "home page". It fuckin worked. I turned Grammarly back on and clicked the link and sure enough it failed.
I made him a browser shortcut, moved his "email shortcuts" into his browser, blew his mind, and closed the ticket, but it definitely bugged me.
This tracks because it was some very dated camera software (you'll know what I mean if you've seen it) and the link was to his customized homepage with a super long php (or something) generated url. He was the only one at the site with Grammarly as well so it was the only time we saw the problem.
Thank you, I can finally close this cold case out in my brain.
If a website bug is not easily solved, first order of troubleshooting is to disable all extensions. Devs don't often think an extension could be causing the problem, but extensions can do wild things to a webpage. I've caught a few bugs caused by extensions this way.
This is not an extension. It's some other kind of plugin or weird hook. They tried disabling all extensions first thing.
"Hunch #2" in this article is about extensions causing problems. That is what my comment is in reference to, but maybe you didn't read the article.
Sorry but there is no rule that every comment made about an article must be specific to the outcome of an article about troubleshooting. I can comment about other things covered in the article too.
Once my college professor was working on her research paper and told me she was struggling get text to stay underlined. Assuming a simple user error, I expected to help her out in 5 minutes.
Over three hours later, we discovered that the combo of her specific video card driver version along with her specific printer driver version would keep text from printing out underlined.
Much better than the Xerox bug that caused numbers in scanned documents to get changed.
https://www.zdnet.com/article/xerox-scanners-alter-numbers-i...
Ouch
I kind of remember this one. It wasn't really a bug. I think Xerox used software that was known to not be 100% trustworthy to recognize numbers when used at a certain compression level. It was even in the manual if i'm not mistaken.
The manual pointed out this can happen at higher compression levels, but they were able to reproduce it at all levels.
How does one discover something that niche in ~3 hours?
Lots of internet searching and even a few calls to HP support. To be honest, we dismissed some of the earlier suggestions to upgrade the other drivers from other vendors... so maybe most of the time was us getting past ourselves and our disbelief.
Huh? How does a video card affect printing?
One of the ways to print things (especially on windows) is Via GDI. [0]
Basically using the OS's rendering to make a raster that is then sent to the printer. The main thing the printer's driver does in this case is know how to take the bitmap and tell the printer to print the bitmap (i.e. chunking data and/or sliding the right commands into the bitmap stream)
Contrast to, say, PostScript which allow for more compact and better scaling definition of what to print. This obviously works better for quality, however for a long time the issue was you then had to have sufficient processing power on the printer itself to handle it.
[0] - Search for 'GDI Printer' for a little more info.
Interesting! So that's why I used to get crappily rasterized printouts of PDFs in Chrome a few years ago.
I had thought printers could be trusted with their own rendering, but of course that is another can of worms...
More relevant to the bug is the fact that GDI can do its own rendering, or send commands to a driver, usually for GPU hardware acceleration, but the same applies to printers.
It often did, particularly on older versions of Windows. I helped uncover a bug in Epson printer drivers ~20 years ago that was caused by a specific graphics card.
20+ years ago I was in tech support and had to help someone figure out an issue where her document wouldn't print on a Brother printer. Turns out a section divider line would block the entire doc from printing (by crashing the app) if the line's end-cap style was set to square rather than rounded.
A lot of rendering will go through the video card if available, like the jvm does this as an optimization.
Ah interesting. That makes sense. I had no idea.
Even if you have crash reporting disabled there should be a .dmp generated somewhere in the user profile directory. Manually uploading that to a bug at https://crbug.com/new would allow a Chrome developer to debug it.
If you can't share the dump for similar reasons to why you have crash reporting disabled, you can build minidump_stackwalk from Chromium and use it to generate an unsymbolized stack trace that you can post to the bug. A Chrome developer can then symbolize it.
https://www.chromium.org/developers/decoding-crash-dumps/ has some more details.
What an interesting conflux of tech to create this bug. That's the web in 2023. I would love to know if it was a Chromium bug that got resolved, but navigating this is tough: https://bugs.chromium.org/p/chromium/issues/list?can=1&q=gif...
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
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.
They should definitely publish the gif
Something like this https://bugs.chromium.org/p/chromium/issues/detail?id=129770...
I randomly had the issue that after booting up Linux, I didn't have any sound. Turns out it was related to my Windows dual-boot setup!
When restarting from Windows, Windows doesn't shut down my realtek audio device, but only puts it to sleep and Linux fails to start it. Only solution is to always do a shutdown from Windows and then hitting the power button. The issue is still there: https://askubuntu.com/questions/1032543/no-sound-in-ubuntu-1...
I've seen the opposite-ish: Someone who was dual booting windows and linux only had working wifi if they booted into windows and rebooted into linux. The linux install didn't have the firmware package for their wifi card installed, so when rebooting from windows into linux it was still all primed and ready to go but not when cold booting into linux directly.
This is my exact problem with a HP envy X360. HP refuses to fix the bug in BIOS. :/
Every other day I read some fascinating HP adventure. I've done some questing myself, cant really tell if I did well, are they new multiple issues or the good old same?
Your comment had me wonder if a kickstarter for an rpg game called HP printers would take off. The potential fan base is HUGE, I imagine even people who would never play a game would want to see it.
Let the GUI be like little computer people (only an office)
https://youtu.be/SkTgX1mGmDg?t=17
Then the player has to go though rituals depending on the HP printer type, swap old for new then new for old then old for new ink cartridges after finding the instant ink package in storage, if any spawned of course.
If you try to go to fast the hero starts destroying the office, starting with the printer. Then a new different model is delivered. Ready for setup.... or maybe not?
In some laps of consciousness I purchase one more some years ago. The hours of configuring it made me feel dumber than the wrath of the HP dungeon master.
The ISP has a wifi router fixed on channel 11, half the neighborhood sits on channel 11, range is about 4 meters, the printer doesn't reconnect unless unplugged first. But there is wifi direct, this doesn't have 50 cm of range, it wants to use channel 11.
in the game our hero at least at first doesn't know about channels. The next printer arrives: Something seems off, there is no usb cable in the box? Do you want to A) order a cable B) we will use wifi! Of course if you order the cable the boss will complaint that it takes to long to set up the printer but when you eventually get the cable the boss wants to print from his phone...
> Your comment had me wonder if a kickstarter for an rpg game called HP printers would take off.
The thing is, a lot form people are already playing this game, which limits the appeal of the simulation version.
Had the same thing going the other way: rebooting from Linux caused Windows 10 to bluescreen during boot.
turning off fast user switching didnt fix it?
once observed similar behavior with my bluetooth device years ago.
I agree with the others here about the ending being a total letdown.
Unfortunately, with access to neither the Chrome source code nor the Grammarly source code, we can only guess.
Is this what the "open source" movement has created --- developers who are totally lost without source code and refuse to dig deeper? Of course the corporate interests who don't want us to know the truth, because their profit depends on it, would absolutely adore such propaganda...
I still remember a time when a lot of people would disassemble, understand, and patch programs without source --- and many of them weren't even career developers; it was just a way to get software to do what one wanted, and driven by that motivation, one would naturally learn enough to do so.
The article also touches on another point worth mentioning: the amount of complexity in the whole stack is insane. Seeing all the frameworks upon frameworks being name-dropped, I can't help but feel like a lot of this is self-inflicted.
When I removed loader-spinner.gif, the placeholder we display while the menu options load, the page stopped crashing.
Do menu options take long enough to load that they need a loading animation?
Expecting every developer to be able to patch a binary is, to put it politely, unrealistic.
The world of software engineering is enormous, and knowing all parts of the software stack hasn't been remotely feasible for a very long time.
Also consider the fact that software engineering is a journey of learning, and every one of us is on a different part of that journey.
Very well said - even with open source there seems to be a general lack of willingness to actually read code, let alone crack open the disassembler or attach a debugger - the skill is apparently not taught anymore
Presumably they make a network request to get the options. So it makes sense to have a loading spinner just in case it takes a long time, even if it's usually near-instant.
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.
I added
to all pages in a single-page-web-app after discovering some bug or other with Chrome screwing up the page.<meta name="google" content="notranslate">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...<html translate="no">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!
I first read this as "translate to Norwegian"<html translate="no">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.
It's the reverse-Norway problem - https://news.ycombinator.com/item?id=26671136
I know what you mean, but this caused me a second of "wait, what?"
> all pages in a single-page-web-app
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 the USA, 20% of computers still run on coal!
https://www.eia.gov/energyexplained/electricity/electricity-...
I wouldn't want to disallow translation, but in this case it was unnecessary anyway.
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.
[1] https://bugs.chromium.org/p/chromium/issues/detail?id=872770
What was translating from English to American or something?
From English to Turkish but Google won't just leave the parts that are already in Turkish alone and subtly reword them instead for some reason.
you should submit this story to DaylyWTF or smth
it's hilarious
This is _so_ familiar!
I have seen accessibility tools in Chrome lead to this kind of issue in the past with a dropdown menu -- to the point where it could be replicated with a miniscule amount of HTML. The particular bug I hit 2 years ago was in Chromium-Edge, but the symptoms and cause were very similar.
Grammarly almost certainly leans on some of the accessibility tools in Chrome. These tools are somewhat different in the various Chromium flavors (Edge, Brave, Chrome, etc.).
So the theory would be that grammarly desktop sees the gif (what? How?) and calls some browser accessibility function on it (or?) which chrome cant handle and it crashes?
With the bug I saw years ago, just having certain accessibility features of the browser enabled _at all_ caused the bug (we were able to temporarily mitigate by disabling some obscure Edge accessibility feature via a launch parameter). So, my theory here is Grammarly is just enabling an optional accessibility feature in Chrome that has this bug when trying to "read" the gif.
Perhaps it has an extension that it installs that does this?
They did try disabling browser extensions, according to the blog post.
Next time this happens, I recommend just letting people use a different browser. Firefox in particular has gotten much better at importing bookmarks, passwords, etc. from Chrome.
It was a Sign from the universe that it was time to make the switch. Who are we to reject Signs?
(Full disclosure: I'm an engineer on Firefox. But that has nothing whatsoever to do with my advice here, no siree Bob, not in the least.)
As an engineer, yes Firefox is a good solution
As a PM, we spent 4 months making the onboard easier, and now you want people to install a new browser?
Having multiple browsers as a standard installation and employee training is an investment in business continuity.
And business continuity investment is like insurance: A waste until you need it.
Too much monoculture is short sighted and long term expensive.
Do you ship them extra computers too? Dual boot? There's gotta be a limit somewhere, and browser choice is a fair one.
For engineers, absolutely, two browsers because some are liable to hit (self or team induced) bugs. But for sales? Support? Nah.
I run into Firefox compatibility issues waaay more frequently than chrome compatibility issues, for obvious reasons. Even extremely obvious issues, like 2fa login not working on mobile Firefox, are surprisingly common to find, so I'd never install Firefox as a primary browser for non-techies nowadays. I use Firefox myself for ideological reasons, though.
This is explicitly stated as a workaround in the linked article.
Chrome is over half the market. Not a good sign for a browser based product to not properly work on the most used browser on the world...
I love the corporate security policy that disables Chrome crash reporting for security reasons, but allows employees to install Grammarly.
Reminds me of the time back in 2010 when a piece of CSS on the Yahoo Search page would cause a complete desktop crash on Red Hat Linux: https://tech.bluesmoon.info/2010/04/can-website-crash-your-r...
To the author, did you ever consider contacting the Chrome dev team about this? They're pretty responsive to bug reports.
Grammarly is an ipso facto security hole that is extremely likely to be pwned or controlled outright by a number of state security services. It should be treated like malware.
It’s hard blocked on any corporate devices where I work.
Ah, Tsutomo, my learned disciple!
If they can figure it out, they're sitting on potentially a very valuable exploit.
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 ;)
It wasn't the Grammarly extension, it was the desktop app.
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).
I'd also be interesting in seeing the raw .gif file - as a hobbyist wannabe researcher myself, I'd love to investigate this.
One that's been patched already, though, as they say that in current versions of Chrome and Grammarly it doesn't crash.
I gotta say, the ending was pretty disappointing. I was so hyped to learn why Grammarly crashes when Chrome loads a particular gif. What about the gif was different? What part of Grammarly made that happen? I hate to say it but this is modern web dev in a nutshell. Remove stuff until you find where the bug is, tweak it randomly until it's fixed, done. No root cause analysis or anything deep.
This is a great post anyway. Well written and still quite intriguing right up until the end. And it seems lots of comments on here seem to also know about this problem, so I think I can still satisfy my curiosity.
> I hate to say it but this is modern web dev in a nutshell. Remove stuff until you find where the bug is, tweak it randomly until it's fixed, done.
I’ve alternated between frontend, “full stack”, and backend roles for over 20 years. It’s my experience that what you’re describing is “dev in a nutshell”—neither “modern” nor “web” in the sense you seem to mean. And in any case it’s highly situational and variable depending on the dev and their team.
They never root caused the bug! They know a symptom (Grammarly and this gif cause things to crash) but still no root cause. I was pretty disappointed at the end.
It was like reading a Sherlock Holmes story where they just decide to put Moriarty in jail and that fixes everything, but Holmes doesn't actually figure out what was going on.
> When I removed loader-spinner.gif, the placeholder we display while the menu options load, the page stopped crashing. Eureka! It’s the gif! We swapped in a different gif and the page did not crash.
I would love to have the original and the un-crashy gifs mentioned. It's super easy, generally, and even without an extensive knowledge of image formats to get a grasp of what might be going on and then going down some really exciting rabbit-hole of image encoding/decoding issues.
Just take the two gifs and run them (one by one) through ImageMagick or GraphicsMagick to print out the details of what's in them, and look for differences.
Assuming ImageMagick is installed (or GraphicsMagick) installed, something like:
#imagemagick
$ diff <(identify -verbose loader-spinner-CRASHY.gif) <(identify -verbose loader-spinner.gif)
#graphicsmagick
$ diff <(gm identify -verbose loader-spinner-CRASHY.gif) <(gm identify -verbose loader-spinner.gif)
...and rabbit-hole away
EDIT: formatting
> No root cause analysis or anything deep.
Spending time to create a test case and sending it to the browser bug team gets the bug fixed? Riiiiiiiiight.
Actually I did that for a while and the Chromium team would occasionally fix some fairly subtle issues: assuming I could make a demo of the problem and took the time to write up a good bug report. Maybe they just liked me! The Chromium team also wrote fantastic public followup to bug reports (whether fixed or not).
Certainly I never had any luck getting even extremely serious browser bugs fixed by anyone else (Apple, Mozilla, Microsoft) regardless of how much time I wasted trying to give good informative bug reports. And you never found out anything further - talking to walls is more productive.
It feels good trying to help the world be a better place, but it wasn't worth it.
Don't waste your time fighting windmills. Find a workaround, document it with a comment, forget about it. Do something that makes your business successful instead.
And when you consider they end with the pitch "If you also enjoy collaborating with relentlessly curious people, we are hiring!"
What is effectively guessing which is what this article entails - without knowing the actual cause - hardly qualifies one as "relentlessly curious".
Personally I deeply dislike the random walk towards insanity that modern dev takes with the constant churn and layers of fixes upon fixes - react state is no good! use redux! use this! use that! And before you know it knowing what is actually going on becomes nearly impossible!
> I hate to say it but this is modern web dev in a nutshell
I'd rather call it scientific method: observe, form a hypothesis, experiment and analyze results.
I agree it is anticlimatic to not know the root cause, but the rant about the current state of web dev seems out of place. We dont even know if it was because a web technology.
Some folks were mentioning issues from printers being caused by graphic cards drivers. One would love to blame printers, but it turned out they were not the culprit.
Agreed.
> Unfortunately, with access to neither the Chrome source code nor the Grammarly source code, we can only guess.
Chromium source code is open. They could also certainly try different versions of Chrome to bisect when the issue has started to happen. Isn't there a chance perhaps this crash might actually be disguising a buffer overflow vulnerability as well? Typically user inputs aren't supposed to crash browser/renderer processes.
They allegedly tried chromium without luck.
It is so satisfying to finally identify the root cause of such an obscure bug. Of course, along the way, you will shed tears. Sometimes literally.
I had a funny one a couple of weeks ago: Text on a button would sometimes not display. After much experimentation, it turned out that the text would display unless the character 'D' was present. It turned out that the sizing of the buttons was just barely large enough for the font-size selected, and apparently the 'D' in the selected font was microscopically taller than other characters.
FWIW I have to thank ChatGPT for helping solve that one. I explained the problem, and it gave me a list of things to try...
Shared library like libgif used by both Chrome and Grammarly but different versions?
Another favorite bug investigation of you're into this sort of thing: https://www.pagerduty.com/blog/the-discovery-of-apache-zooke...
For security reasons, your organization disables Chrome crash reports but allows the use of Grammarly, an app that essentially functions as a keylogger. Consented or not, it’s a keylogger.
https://support.grammarly.com/hc/en-us/articles/360003816032...
The weirdest bug I've seen yet was a concurrency race condition which led to 'spooky action at a distance'. Every time I tried to console.log() to observe some value to see the cause of the bug, the bug would go away.
But alas, I hadn't discovered some new quantum effect... It turns out to have been because the race condition was close within maybe 1 millisecond and adding the console.log() statement there meant that one part of the code would take a bit longer to execute and so the race condition would not occur.
In Qt QML using print can lead to different behavior very very quickly since their engine creates bindings on whatever it comes by so using two variables in a print statement can lead to different behavior than just using one. QML in general is just awful.
The thing that struck me here is that Chrome crash reporting is disabled for security reasons, presumably not wanting to risk customer information being sent to a third party, but Grammerly is apparently fine? How is a tool that sends literally everything you type to a third party ok, but one that maybe sends something if the browser crashes isn't?
Because doing that is a core part of Grammarly, i.e. they can argue in court that the user should obviously expect grammarly to send the data to their servers. Sending crash report data is not so, as it is not essential to using the service.
I've actually seen something like this in the wild myself. For awhile there were some GIFs that if placed in Discord, would cause it to crash for everyone who was looking at the chat.
Admins had a fun day when that was found!
I discovered a bug like this with GIFs too. It turns out some gifs can be encoded such that it is animated and a single frame long.
Can’t remember the exact event name now, but the browser fires a play event when gifs loop.
This particular gif was issuing too many of these play events that made the app super slow and freeze since it was doing some work in those handlers.
We had a bunch of crash reports and bug reports. None of those showed the actual gifs our customers were using. When we asked for the actual gif, we immediately spotted the problem.
The true bug in the photo is a "candy-striped leafhopper", Graphocephala coccinea, which is tiny but has very striking coloration.
The Larvae of leafhoppers are commonly known as spittlebugs, which create protective bubble nests while feeding on plant stems
What a cool mystery-solving post! I wish all technology writing were this clear and explanatory.
For another fun debugging tale, google: Mazda radio Seattle NPR bug
Holy hell lol.
I'm guessing this is the webp bug.
The auto conversion to webp on the backend, signaled by chrome, resulted in a bad image that crashes the browser due to grammarly parsing of said bad webp.
Safari doesn't tell the server it does webp and so it downloads the actual gif, and doesn't crash.
GIFs don’t get automatically converted to webp files.
says who? any web server (nginx, whatever) can be told to do this
Yes, but why would it?
because it's super convenient, and improves performance?
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.
Was it actually a Chrome bug though? It only happened when the Grammerly desktop app was installed. My guess is grammerly is doing something sketchy.
Maybe adding Grammarly created enough of a lag causing the GIF file to be shown?
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."
I'm thinking the same thing. It could be that Grammerly injects it's own loading spinner with the same filename into the HTML.
I wish they tried to simply rename the file instead of remove it.
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.
But only in Chrome. Not necessarily inconsistent with what you’re saying, just an interesting wrinkle.
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.
Is there a copy of the gif available? That’s interesting
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.
[1] https://en.wikipedia.org/wiki/GIF#Example_GIF_file
[2] https://www.w3.org/Graphics/GIF/spec-gif89a.txt
[4] https://github.com/HexFiend/HexFiend/blob/master/templates/I...
Another good option is ImHex which is an open source hex editor that supports file patterns. The gif pattern is one of the patterns already available:
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 have a saying that isn't perfectly true but often will apply to "fixes" like this -
If you don't know why the fix worked, you may not have actually fixed it.
But they couldn't fix the bug: The bug was in another product that they couldn't access source code or submit patches.
The best they could do was work around it.
Sometimes workarounds are the best you can do until your vendor provides a real fix.
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.
They said it also crashes when they just load the gif. It seems hard to believe they always had tons of tabs open for these tests.
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.
Maybe, but they don’t know another GIF couldn’t eventually cause the same issue again.
But you may have
Ahhh, Schrodinger's patch.
Schrödinger's bug?
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.
Grammarly is awful. I remember adding custom grammarly attributes to sensitive password fields so that Grammarly would not read and store our users' passwords inside their service. So nasty.
This company would sure make a great asset for the FBI, NSA and CIA given that they're so interested in snooping in on foreign language speakers; which happen to be grammarly's main demographic. The thing is malware.
Update: After writing this comment, me and my wife started getting Grammarly ads. Awful.
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.
Up there with the "I can't send an email over 500 miles" story
I love this one so much.
Vapor lock. Legend here: https://www.snopes.com/fact-check/cone-of-silence/
I heard a similar tale in high school.
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.
This one is a legend. I love it, but you can find the debunking on the fact checking sites.
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?
It's a just-so story. The null hypothesis is that it's not true.
That is the definition of null hypothesis, yes.
Not to be blunt, but you might get a closer shave with Occam's Razor.
The null hypothesis isn't "it's not true" it's "what's has the highest prior probability?".
If my wife said "I'm going to the shops" I wouldn't assume she was lying until proven otherwise.
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....)
> The code for our main navigation bar has a fair amount of metaprogramming, and chasing down threads here was often more confusing than not.
One more point for Don't Be Clever. As Brian Kernighan put it: “Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”
When I reached the "Stroke of Good Luck" title, I put down my phone and tried to think what it could be based on what I know before the reveal.
It was really hard to generate thoughts of the form "subsystem x causes the crash" and not of the form "try to do experiment x next", but here's what I came up with:
- a headache trying to think about it - if it's not an extension, it's likely another piece of software that has code running in the browser, like PDF plugins used to before Chrome started handling PDFs itself - the crash is in one of the browser subsystems, so either in the JS engine, the GPU code, the layout engine, the parser, some format plugin (video? pdf?) or the network code. Some format plugin is most likely of these to only crash for tech support and remote developers but not devs
Seems I was pretty close. After doing this exercise I would probaply have compared lists of installed software between staff who see the bug and those who don't, which would have solved it. My takeaway is that Zen debugging (just thinking what possible causes the seen behavior could have, without atking any new actions or measurements) is useful even when it seems completely useless and causes a headache.
Ah yes, the great fun of bug-hunting. Probably most people in working IT have some stories to tell about this.
One thing that comes to my mind happened in a company where they used a simple software to create medical reports. One clerk suddenly started creating "broken" PDF files. I debugged this for hours and could not find anything. At some point, I just copied the full raw text content that the clerk had written into one of those files out of the database into Sublime Text and I suddenly saw a small box appear between two characters of one word. It turned out that this clerk had created a Word document with text templates. Some of those texts were copied (at least partially) from other documents or websites. Apparently, either something went wrong while copying some text, or there was some control-character embedded for whatever reason in that text. I don't even remember what we did to prevent this from happening anymore, but one single "invisible" character can really cause a lot of trouble.
Another point is of course if you have strange side-effects just by combining specific software. Back in the day when Crysis 1 was new and popular, I was a little involved in the modding-scene. At some point, my CryEngine editor would refuse to start up. I reinstalled it and tried to debug it, but I could not find anything myself. So I turned to the forums and found a thread where a small group of people had the exact same problem. We all shared our setups and - basically by accident - found out that we all had Wacom tablets plugged-in to our computers. I don't remember if it was enough to unplug the devices or if we also had to uninstall the Wacom drivers, but one of those things fixed the issue and we could all continue to build beautiful maps in the CryEngine.
Btw, I am now suddenly constantly aware of my Grammarly plugin ...
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)
If you can grab a crash log I am sure the Chrome team would be happy to look at it.
Most bugs are software issues, though.
This reminds me of an old Chrome bug we ran up against involving the auto fill feature. All day, our software users are entering patient data, including address information. Chrome would grind to a halt on certain pages trying to provide all their previous entries as auto fill options to the form fields. Our sysadmins disabled the Chrome feature for all of our internal users and the issue disappeared.
alert(banana++)
If it is just you and your application you can just spray paint from the hip the alerts from top to bottom. After each line of html you can have one more <script>alert(banana++)</script>, in the middle of your css </style><script>alert(banana++)</script><style> etc
If there are uhh thousands(?) of people actively using the page you put just one alert some place in the middle.
Everyone will have to click on OK, the page crashes. You ask the crashee: Did it crash before or after the "make America great again" alert message. (call it something they would remember)
Now you know the issue is in the top or bottom half. You move the alert to half way the half with the issue in it. If you can get some sort of reasonably consistent crashing you will find it pretty quick even in production.
Hope this helps, or maybe it is a stupid idea and you could explain why.
Spoiler alert But if you read the article... ;@)
Improper animated GIF decoding is potentially a bug and potentially a security vulnerability. The reality is this leads to duck-tape workarounds and greater tech debt on the production side of the web. Sigh. There are standards, there are expectations, there quirks across N implementations, and MxN layers of duck tape in M consuming implementations. Just one implementation intentionally or unintentionally being different causes M headaches.
Also fun Chromium-derived browserisms:
- Updating while open is allowed and leads to silent and not-so-silent breakage.
- MSFT MDE causes unexpected breakage in fun ways every now and then, including the cause of a crash while dragging a tab on Windows.
- Some flavors of Chromium browsers are broken with IPv6 enabled, leading to an ERR_NETWORK_CHANGED on every nth page visit.
Hash collision?
What?
I've run into something similar to this a few years ago where chrome randomly introduced a rendering bug that resulted in a similar crash and only affected our application in seemingly random fashion. I don't remember the full context but I think it was something involving layers & transparency.
We finally figured it out when a coworker couldn't replicate and we noticed they were a version of chrome behind. We were able to track down the specific commits in chrome that broke & fixed it in our case which was pretty cool to see at the time.
If you have any more time I recommend reading through the commit log and see if you can find the changes that broke/fixed this for you. I'd bet on another rendering bug.
Can you share the `loader-spinner.gif` ? Preferably over a service that does not recompress it.
> Using open-source Chromium instead of Chrome did not cause crashes, so we couldn’t see what Chrome code was failing either.
They don't address why they didn't just run Chromium. Or Firefox.
(This is potentially better than the 'solution' they much later ended up with, in which they probably only relieved a symptom of an underlying problem that can exhibit again, and in the meantime is a zero-day exploit waiting to happen. At least, with a different browser, there's a chance that the vulnerability doesn't actually exist, when it's known to exist in their Chrome configuration.)
> They don't address why they didn't just run Chromium. Or Firefox.
The article implies that Gusto's employees can whatever browser they want.
And, honestly, telling your employees to run a browser that only techies have heard of sounds like a really dumb idea.
> The article implies that Gusto's employees can whatever browser they want.
For users of their security-sensitive internal software?
> And, honestly, telling your employees to run a browser that only techies have heard of sounds like a really dumb idea.
Sounds like they're using this for internal tools, as a kind of thin-client layer. They could recommend or mandate a particular browser, and people would just use it. ("Click this icon, and a window opens with our internal tool. It's pretty much the same as any other browser, as far as you care.")
As an employee I would be really upset if you forced me to use a specific browser to do my work.
I have been forced to use IE for some internal apps when I was working in investment banking. It's not that bad.
What makes this doubly frustrating is that they also didn't report the bug to Chrome. It's super easy to do, plus they're very responsive if you have a repro case which in this case they do. I think I'm now up to three or four Chrome bugs reported that their team has subsequently fixed.
They said it wasn't reproducible anymore though. So if they make a bug report now and say "this used to cause a crash in an old version of Chrome while also having an old version of another software installed, but is no longer reproducible in latest builds", most people would probably just ignore it.
It was reproducible at the time they found it, and trivially so: install Grammarly, drag this GIF into Chrome, and it crashes. I understood everything up to the point where they just changed the GIF and moved on without ever telling the Chrome or Grammarly folks about it.
> They don't address why they didn't just run Chromium. Or Firefox.
Probably:
1. Because it is reasonable to expect the application to work in Chrome.
2. Chromium isn't intended for production use cases.
Back when IE and Chrome had about equal market share, I worked somewhere that had one team insisting that all employees must use IE for one of their applications, and another team insisting that all employees use Chrome for their application. 50%+ of support calls were employees confusing the two browsers.
I don't think the post you quoted is implying that they should've closed their eyes.
It makes much more sense to try a different browser first and see if the problem persists. Instead of test versions and extensions.
> As urgency waned because our users were using other browsers as a workaround, progress on this bug slowed to make way for other priorities. We didn’t have much left to go on without being able to reproduce the bug. However, we wanted to resolve it since users had bookmarks/settings/preferences in Chrome. We believed that we shouldn’t have to ask our users to avoid the world’s most popular browser, and we were also still getting periodic pings from various users asking whether we had made any progress on this bug.
The post I quoted itself quoted the article saying they did test in Chromium. The article also says they tested Firefox and Safari.
They say in the article that the bug became a much lower priority because their employees simply switched browsers
You really want to change an entire company’s mandated browser every time a bug causes a problem with an extension?
You must not have read the article because he literally addresses this.
*She – the author’s name is Amy
Maybe Grammarly doesn't work for Chromium? (guessing)
tl;dr: a certain GIF would crash a Chrome tab, but only when the desktop version of Grammarly was installed. (Not a Chrome extension.)
That's insane!
Can anyone think by what possible mechanism the installation of Grammarly could affect whether a .gif file would crash Chrome?
The company seems to be on Macs since they report that the problem doesn't surface in Safari.
Is there some kind of dynamically-linked GIF decoding library used by macOS that Chrome relies upon, and Grammarly somehow installs one that takes precedence for all applications? I didn't think this would be possible -- I thought image decoding was done natively in the browser and not outsourced to the OS, for security reasons.
Maybe, the GIF contains a text comment and Grammarly not only accesses this, but also alters it (for whatever reason), thus overwriting the file in a way in memory that offsets in the GIF file or its in-memory representation are violated?
It's not an uncommon problem unfortunately. On Windows the OS lets programs inject DLLs into each other's address spaces, and this is actually a very common programming technique for various reasons. Apps don't expect it to happen of course, and so this is a fertile field of bugs.
Chrome does in fact attempt to block some apps from doing this because they're known to cause crashes. You can see the blacklist here:
https://source.chromium.org/chromium/chromium/src/+/main:chr...
They don't like apps doing it but you can apply for an exception:
https://sites.google.com/a/chromium.org/dev/Home/third-party...
So my guess is that Grammarly is injecting code into other processes, probably to try and gain access to their text controls so it can Grammarlyze stuff, and somewhere along the line corrupts the heap or stack in some way. The GIF aspect might be a red herring, as the crash was IIUC never reliably reproducible. Random crashes that happen sometimes but not others is strongly indicative of something being randomly corrupted.
Or it could be something else. Chrome moved to blocking third party injects by default some time ago, so maybe that's also a red herring.
This would be strange since macOS should not let Chrome load libraries that aren’t signed by Google.
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.
If Chrome is able to generate a crash-report, nothing would prevent you to intercept it.
> Unfortunately, with access to neither the Chrome source code [...]
I mean, it's still very possible to debug (especially with the fact in mind that Chromium is open-source, and for me has been a very useful source when reverse-engineering and debugging Chrome), but I understand why web developers would not be trained in reverse-engineering techniques.
We used to develop software that used the Windows Accessibility APIs (UI Automation). On certain versions of Excel with some files it would crash the client application with a null pointer exception once you try to read the window name/class. It would be interesting to see the cause of the crash e.g. a core dump/user-mode dump/event viewer log.
I can't remember the details anymore but the craziest bug I ever found was one that would crash the page whenever Chrome's Developer Tools were opened. I ended up having to use an embedded JS-based dev tool to figure out what was going on (I was a pretty junior developer and didn't have any better ideas at the time).
The main reason for tabs to crash is running out of RAM.
Never do you see the guy investigating memory usage, which is weird.
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.
If that were the case, I think the bug would be much easier to reproduce; and be a lot more widespread.
Honourable mention, “we can’t send emails more than 500 miles” https://web.mit.edu/jemorris/humor/500-miles
I feel the author might have missed out on a multi-thousand dollar bug bounty.
I wonder if they checked for exploit code in the image the they likely originally found somewhere on Google.
Ah, Chrome and slow spinners.
Python tests were taking ages on VSCode due to an SVG spinner:
https://bugs.chromium.org/p/chromium/issues/detail?id=103626...
> Turbo is a gem we added to speed up our Rails application, but it turned out to be a red herring: it was only introduced after the bug had already been reported, and we learned that the engineer who introduced it had actually been experiencing these Chrome crashes for months prior to Turbo being introduced, and months prior to the bug being escalated to us.
lolol I can just imagine the engineer working on this: "huh, it keeps crashing, that's weird. Oh well, it was like that when I got here. ship it"
The blink debug logs would probably be pretty useful for the engineers involved...
oh and there's this one: https://web.mit.edu/jemorris/humor/500-miles
And that's yet another reason that we must have several different browser engines.
Maybe the name was odd `loader-spinner.gif`
I don't think I would believe myself if I found this being a specific gif. This is a great amount of coincidences in code to cause this.
Grammarly is an application that I don't get. The fact that people are installing, basically spyware, on their computers just to get grammar suggestions to make their writing more boring and add a spellchecker (which is already inside web browsers) is pretty astounding to me. The fact companies allow employees to have it, despite obvious security issues of sending everything one types to a saas, is even more wild.
People that are comfortable with text-based forums may not realize the extent of illiteracy and semiliteracy in the US. Decades ago, a small company was able to convince most of the education system (public and sometimes private) to use a teaching method based on junk science. The end result is that there are many millions of adults in the current workforce who can barely read, and many of them work in office settings. Some of those would install anything that would help them through text-based communications.
[1]: "How a flawed idea is teaching millions of kids to be poor readers" https://www.apmreports.org/episode/2019/08/22/whats-wrong-ho...
[2]: "Sold a Story: How Teaching Kids to Read Went So Wrong" https://features.apmreports.org/sold-a-story/
[3]: "According to the U.S. Department of Education, 54% of U.S. adults lack proficiency in literacy, reading below the equivalent of a sixth-grade level" https://old.reddit.com/r/todayilearned/comments/rqulik/til_t...
It's odd to read the story of an adult who believes they're a poor reader, still to this day apparently, because of what happened to them 30 years ago. Odder still that the article leaves itself the only conclusion of going all the way back to grade school and trying an entirely different strategy and hoping that just "works out" in the end.
The lack of "continuing education" in the era of the internet is baffling to me.
I think about this a lot, too. My academic interests are pretty broad, and I could improve in every subject, so why don't I? I think there are two reasons: a lack of focused effort, and the steadily increasing demands of adulthood.
I do reasonably okay at self-guided education when I want to, but there's definitely a difference vs. a structured secondary education environment, where there is accountability and other people to guide each other through the process. And, that's coming in to those subjects with already a better-than-average literacy and numeracy; I have to expect that for people who struggle with grade school reading comprehension or math, trying to bootstrap those abilities alone would be daunting.
Also, there's just less room for pursuing those now. Lots of people are getting squeezed by concerns that aren't part of most childrens' awareness -- housing costs, bureaucracy, the treadmill of maintaining all the machines that get us through daily life. Those add enormous pressure to dedicate more time towards professional development and "getting ahead", or at least not falling further behind, and that has been eroding all of the unstructured time that I would spend working my way through a textbook (or online class). People with poor literacy are probably more likely to have lower-paying positions, so all of those demands are even more severe.
Not that it's impossible. Lots of people do manage to self-educate their way out of poorer circumstances, and certainly the internet has made that far more accessible than it was before the turn of the century. But, let's not underestimate how challenging it is, either.
> My academic interests are pretty broad, and I could improve in every subject, so why don't I?
My suspected culprits:
1) The massively increased complexity of ordinary living is overconsumining our personal resources. and
2) For post-GenX and later, the erasure of childhood (free-roaming & peer-only hours) sabotages[1] the reward systems (joy) that supercharge early learning.
The less joy there is to facilitate learning, the more effort is required (from otherwise overly depleted resources).
[1] similar to what abuse and neglect do
Isn't the opposite true with regards to complexity of ordinary living? We've specialised so far that most people aren't required to or even capable of sewing their own clothes, hunting/growing/foraging their own food, building their own shelter and furniture. Something our great grandparents would find unbelievable.
Modern living is so monotonously boring and devoid of any challenge that people are find more and more creative ways to try and get an ounce of that physical and mental stimulation back in their lives (hobbies, exercise, gaming, etc).
To reinforce your point: I have dyslexic friends and family that have learnt to write over time. Very difficult, but they have learnt because they had to for high paying jobs.
One friend literally couldn't read. He took himself through adult reading courses. He ain't no Shakespeare, but I can now txt him and get a written reply.
Tech is helping, but the underlying reason for the change is their own initiative.
I would judge that none of the friends or family illiteracy was actually caused by our schooling system in New Zealand. Some people just struggle and our pedagogy will always be imperfect. Certainly I can see some failures in my own schooling that still exist and I would like to see fixed (mostly get rid of 99% of the deep crap).
>The lack of "continuing education" in the era of the internet is baffling to me.
It's all about incentives. That is companies are incentivised to give continuing entertainment for ad clicks, rather than building a world of the educated that may have a better all outcome for society (but probably not the ad companies at all).
she had known thant she has disease, so she can't read well when childhood. but the main point is why her normal daughter was taught same strategy by school.
I'm not sure that's specific to the US, and I don't even think that particular teaching method has been used here in Quebec, yet we still see broadly similar literacy rates and levels.
Last I checked US students rank well and are near the top in most education global rankings, so I think bad education is more of a global problem than Americans think it is. Maybe that's outdated though, I'll do my research.
> Last I checked US students rank well and are near the top in most education global rankings, so I think bad education is more of a global problem than Americans think it is.
US is at the bottom of the OECD PISA rankings (as it is with life expectency too), though on a global basis you're right (better than Morocco or Indonesia on both criteria).
Shockingly Australia has fallen quite a bit from the initial PISA study where it was ranked #4, now almost as bad as USA.
Honestly what surprised me the most from your very informative link was that France is lower than the US! I'm probably biased but I've always considered the French education system to be quite rigorous and well rounded, with a few different education paths to fit different student profiles from a pretty early stage. Especially compared to canada, which in my experience has a rather weak and rigid curriculum.
(Though I dislike the way french and European higher education in general works. You're basically boxed in to your specific domain or degree that you often don't even really choose and changing or switching careers is almost impossible. The choices you make in high school basically define what you can even study in, and thus what you can do for the rest of your life. I think that's one thing the US does super well, even more so considering that degrees are less important there in the first place.)
> You're basically boxed in to your specific domain or degree that you often don't even really choose and changing or switching careers is almost impossible.
This was true 50 years ago but hasn't been true since the 90's or so. France may well be the exception in this, but then again, France is an exception in many ways.
Isn't it still true in Germany? With the different high school tiers that can even make it impossible to enroll for a university degree? Though you are right that I shouldn't say that Europe as a whole is like Germany or France even if it's sometime easy to assume so haha.
Germany tends to be more focused on paperwork, there isn't a German that is even moderately active in business that I know that doesn't have a 'steuerberater', it's overly complicated and the paper tends to be in the lead. Germany has fewer free professions than other EU countries as far as I know, lots of things are regulated and it can definitely be harder to switch. But it isn't impossible and I know more than one German who successfully switched careers, even between regulated industries and academic / business careers.
In France, from what I know there is a fairly strong culture of secondary education that creates an 'in-group', not unlike what you see in the UK or the USA with their top-tier universities, and you are either 'on the plan' or you won't be able to get in unless you are of exceptional abilities and that rarely happens later in life, so I think that alone is sufficient to explain the discrepancy.
In NL you can enroll in higher education basically whenever you want, quota permitting and with the intense competition for such spots from abroad by very qualified young people this too can be tricky, depending on the field. But in NL a university degree isn't a pre-requisite for many jobs outside of academia (and teaching) itself.
Anything to do with technology tends to be more merit based, and achievement there tends to trump formal education, and by the time you are 40+ that formal education tends to be weighted far less than when you are say 25 and just out of school.
Other countries would add more to the pattern of variability, there is a huge difference between say Poland or Romania or the Nordics or the Baltics, further reflected in the weight that which a diploma or degree from such institution would carry, especially abroad. For instance, right now in the Baltics there is something of a brain drain happening with the younger generation moving West in droves and so as an older person it is stupidly easy to enroll in a university program. But that degree isn't going to help you much unless you remain in the local economy and the degrees from a decade or more ago are given more weight than the ones that you get there right now because they are fairly desperate for students just to keep the departments up and running.
There are different tiers of highschools and different tiers of higher education.
The first tiers are more targetted towards craftsmanship (e.g. arithmetic and trigonometry you can quickly do in your head, you start working earlier in life, as early as 16) while the latter tiers are more universal and abstract (e.g. math concepts that have better use for computer science, you start working much later, around 25 years old).
You can switch between tiers or fetch later.
Thanks for the details! If you wanted to switch from craftsmanship to say, a more abstract field. Would you have to do the entire 10 years (ish?) of "missed" education?
I know that here in Quebec, you can enroll in university no matter what as long as you are 21 years old and finished high school. Does that happen in Germany? Or is it rare to actually be able to switch between "paths"?
That’s definitely outdated. Literacy rate of my “third world” country is %16 higher than US atm.
Be careful trying to compare countries or even historical numbers when standards vary. The US has a 99% literacy rate based on some metrics, but as often happens when metrics become useless the people tracking them raise the bar.
Thus the US’s “Level 1” literacy rate, which represents being able to follow basic written instructions, was 92% in 2014. But in 2020 the standard changed yet again to: “54% of adults in the United States have English prose literacy below the 6th-grade level.” Noticeably being literate in a non English language suddenly doesn’t count, the prose at 6th grade level is also higher than it’s been in the past.
Or as Wikipedia puts it: In many nations, the ability to read a simple sentence suffices as literacy, and was the previous standard for the U.S. The definition of literacy has changed greatly; the term is presently defined as the ability to use printed and written information to function in society, to achieve one's goals, and to develop one's knowledge and potential.[3] https://en.wikipedia.org/wiki/Literacy_in_the_United_States
What's the functional literacy rate though?
Between the whole language approach to literacy and undiagnosed ADHD, I was very slow at learning how to read. Fortunately, my parents were able to force my grade school to put me into special ed for a couple of years and I rapidly acquired the skill. I have no idea how the teaching methods differed though, beyond classes being half the size and the special ed teacher being accompanied by an aide
I didn’t see a direct mention of it in the links, but is the junk method referred to called Reading Recovery? First I’ve ever heard of it, at least by name. Found it by googling the name Marie Clay that I did see mentioned in one of these links. (Annoying how hard they work to bury the lede.)
If I remember right (it has been a while since I dived into this topic), Reading Recovery was one of the programs mentioned. It was supposed to be a supporting approach to teaching reading to kids who were struggling otherwise.
The mainstream approach that really made a hash of things though was "Whole Language" learning, largely commercialized by Fountas and Pinnell, which eventually provided the program and associated materials to classrooms around the world. This program relied, in part, on guessing: if a child got stuck on a word, they would be asked to guess what word might fit in the sentence. Sometimes they were given context clues, like a picture on the page. Any efforts to associate individual letters or letter combinations with sounds was abandoned.
Wikipedia has something of a watered-down overview of this at https://en.wikipedia.org/wiki/Whole_language, but I really recommend listening to the podcast in the second link in my parent comment (https://features.apmreports.org/sold-a-story/), APM Reports put together a compelling examination of what happened, and it's explained well. (I do wish it was also available in a more typical article format.)
There are a lot of people whose professional outcomes are meaningfully constrained by their ability produce clear business English.
I know a guy who used to get inexplicable feedback about his communication that boiled down to “write better.” This limited his ability to get promoted. He runs all his comms through ChatGPT and asks it to “make this more professional” and doesn’t get that feedback anymore.
I get that people don't care or understand this, but that's also saying he cc's OpenAI, and therefore probably Microsoft, and therefore almost definitely the NSA, on all his business communications. What a world.
People won't care until something major happens and after that they'll implement some draconian half-measure that doesn't fix anything like snooping on office WiFi.
How's that even supposed to work, given that the average corporate ecosystem is so vastly cloud-based now that the majority of services use desktop and mobile apps that pin HTTPS certificates?
Man, I don't know where most of the people here work, but the shit most people write about in their jobs is inconsequential and not super secret. It's performance reviews and meeting notes. 99.99% of the workforce isn't writing about the company's secret sauce... Ever. Maybe director level and up. Also, most companies make physical things, not software, so there's no secret sauce to share through email anyway.
> most companies make physical things, not software, so there's no secret sauce to share through email anyway.
The conclusion does not follow from the premises.
Sure it does. There's no secret to making boxes, or installing glass windows, or making frozen pizzas, or ordering gravel, or installing breakers, or paving sidewalks. Very very few companies make something that actually sets them apart via a trade secret. And sure, there might be some tricks in those examples but it's not putting anyone out of business via being accidentally found a year from now in accidentally leaked partial training data.
My last job was Director of IT and I'm absolutely sick and tired of security fear mongering. Turn on MFA for everything. Boom. You are now secured from 99.9999% of attacks. Chat GPT is absolutely the least of my concerns.
> [...] and therefore probably Microsoft [...]
Where it will go through teams, outlook/exchange, or O365.
Not leaking data is no longer as easy as it used to be. Just some forms are more accepted than others.
As good as the average corporate IT security is that I've witnessed via my work, passing said data to NSA/OpenAI is the least of their issues. Far less scrupulous hackers are running amok as it is.
About 0.1% (0.001%??) of business communication might have adverse consequences for you/your company if forwarded to Microsoft or OpenAI or the NSA. The rest is absolutely fine. And you’re probably already using Gmail or Android or Chrome or Exchange365 or iOS or *something* that could theoretically forward your comms to a tech company (and the security state).
Compared to the alternative of having your colleagues think you’re a bit stupid just because you were raised speaking a language other than English, or your parents weren’t middle class… using Grammarly or ChatGPT is a no brainer. I’d support anyone using whatever tools they can to overcome discrimination and thrive.
The alternatives are:
1. Educate everyone in the company to stop discriminating against people based on language ability (impossible??)
2. Provide a local self-hosted version of the tools (although as a worker at RandomCorp, I would probably prefer to forward all my comms to Microsoft than to management!)
3. Tell people facing discrimination to just shut up and deal with it.
Given the context of an engineer with such poor writing skills that they can't be promoted I'd say the odds anything they write mattering to Microsoft or the NSA are quite a lot closer to 0%. In the only circumstances that it did matter, I'd guess you're not unlikely to be better off with them in the loop anyway since we're talking deep cover industrial espionage.
I've seen people do this on the same week as mandatory trainings featuring this exact scenario. At multiple companies
I’m not sure how to explain this but Microsoft doesn’t need OpenAI to get access to business emails.
I suspect it all started with two Ukrainian who got tired of checking how much of "a" and "the" they forgot to sprinkle into their texts.
I read comments online, and in my experience the most difficult writing to parse isn't from foreign speakers who drop articles or mis-conjugate things - it's from people whose writing is just, for the lack of a better term, bad. This is very common on places like Nextdoor or Facebook.
It's things like:
- total stream-of-consciousness gibberish that could probably be assembled into a coherent statement if the writer would re-read what they wrote and edit it
- A complete lack of punctuation, or even understanding of sentence and paragraph structure; at a glance, it looks like what I described above, but it's different because there's definitely a topic and a point they're looking to make, but they can't put the words together correctly.
- spelling so bad, that even with context, it's unclear what word they're intending to use.
- A wild misunderstanding of how to start and stop conversations online. (One recent example is me asking someone on Facebook if I could stop by to check out a garage sale, and a clarifying question about a term they used, only to get the response "ok." Note that in their post, they didn't specify an address beyond the name of the town they live in.)
You can definitely point out flaws in the way I grew up - somewhat solitary, spending a lot of time alone in my room on a computer connected to the internet - but I think that it at least taught me how to make myself understood in written form.
> - total stream-of-consciousness gibberish that could probably be assembled into a coherent statement if the writer would re-read what they wrote and edit it
This drives me nuts. Did anyone see this [1] on HN the other day? People in comments were springing up to defend this atrocious writing style.
Make a paragraph. Make a point.
I'm not a huge fan of that, but it looks like poetry, and what's more, it looks intentional. The author was going for something, and is probably aware that some folks won't like it.
That's a whole different beast from an email I'll get from a coworker/neighbor where I cannot parse what's even being asked of me, and where the writing is so confusing I don't even know how to ask them to clarify their statement other than to tell them to start over, possibly all the way from kindergarten.
I think that writing style has a point in _realtime_ text chat, where you are racing to get your comment in and turn in the conversation. It’s like a way of streaming your thoughts, not unlike voice conversation - many of the defenses seemed to be talking about that. Not defending it in non-realtime scenarios though.
Oh yeah, I didn't even think about context switching for different communication mediums - maybe my complaints are mostly about people who are used to texting people a series of text messages, in a more conversational way, that doesn't really translate to something like an email or a Facebook/forum post?
I have far more understanding and patience for non-native English speakers making those sorts of mistakes than I do for native speakers.
> Grammarly is an application that I don't get.
You write like a native speaker, so I'm not surprised. But imagine having a few years of school-German, and then taking a German language job. I'd bet there would be times you'd want a writing assistant, too.
There are also plenty of native English speakers who for whatever reason got a crappy education, and didn't get a lot of writing feedback.
As far as corporate security goes, you are correct, and we ban it. But I get why people want it.
> As far as corporate security goes, you are correct, and we ban it. But I get why people want it.
That is what stuck out to me: Installing rando applications on your corporate computer that has access to internal stuff... Whoooaaaa Baby! That's just a security disaster waiting to happen. It's stuff like this that eventually leads to draconian and crappy "Nobody gets admin access to their machines" corporate policies coming down.
Most TechCorp places I worked, if someone installed something like that on their corporate device, they'd get at least a stern talking-to and probably sent back to security training.
Learning a language at school, you will soon be better than natives at grammar. It's the vocabulary, idioms and implicatures that will be tripping you up. Does grammarly really help with those?
hah better than a German at German grammar? don't think so
that.
especially what is puzzling me is:
> For security reasons, we do not have Chrome crash reporting enabled.
so we do not want to have stack traces or whatever else this includes for security reasons, but installing basically keylogger that does spell check is ok
there are companies that forbid using chatgpt for even html development because this could leak company secrets, but grammarly on confluence/jira is just fine
The vast majority of companies don't write any code ever. Not everyone is developing "apps".
If you're going to generalize "everyone" you need to understand your business type is a tiny tiny minority of what most people do.
I worked with someone who really needed it, but we had the usual "keep sales users as far from the actual product as possible" organizational isolation so it worked out in practice. (For engineering, it was on the "don't install this in particular" list.)
I have to wonder whether Grammarly's "Enterprise" tier and its underspecified "advanced security features" involve installing it on-site and offering am "all of your company's words don't get sent across the Internet to another company" feature.
Grammarly is perfectly reasonable product, the major issue is that no adults seems to be in charge at Grammarly This is clearly a product that should never ever be sold a service. This needs to exist solely as a local installation, there is no way to justify the current implementation and someone in charge at Grammarly should have pull the emergency break and demanded a re-implementation.
I understand why Grammarly sells their product as a service, but it's irresponsible and they are just waiting for their Okta moment.
I really like Grammarly as a product, but I exclusively use their web editor. I wonder what their web vs desktop usage is.
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.
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.
more like a murder weapon
Thanks, that’s much better. I wasn’t at all happy with “accomplice” but my mind was blanking on what it should be.
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.
They nuked my account after trying to charge an expired card three times.
The customer response team was extremely quick and responsive telling me their hands were tied.
Fuck Gusto.
Hate that.
“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.
I feel so unsatisfied
Awww. I was really enjoying that; I like detective stories and rabbit-holes.
Then we get to the punchline: "Uh, we fixed the bug, but sorry folks; we didn't solve the puzzle". So I guess we'll never know why that particular anigif crashed Crome but only Chrome, and only if Grammarly was installed (or had been installed during the same session).
I hope Amy Lai lets us know if the story ever gets an ending!
> For security reasons, we do not have Chrome crash reporting enabled.
> We also confirmed with many of our affected users that they had Grammarly installed on their computers.
Ironic.
haha, that was questionable for me as well. It's ok for Grammarly to read your stuff, but crash metadata is a no no.
Welcome to security in 2023 :)
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)?
Maybe they have the enterprise licence with grammarlys pinky swear that they won't train on your data.
Extremely disappointing that they seem to have neither investigated nor enabled others to investigate (e.g. by filing a bug against Chrome).
This smells like a potential security vulnerability.
I was hoping for a bit more of a payoff. Like, if the gif was broken, why did the grammarly extension trigger it reliably?
Such a tease. At least upload the gif so people can poke at it!
Agreed!
I 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?
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.
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!
How could you write all this and not post the gif so we can try it?
Left me hanging, would not post something like this from my engineering blog. They don't have deeep debugging skills at gusto?
Sounds like they have good time management and prioritisation skills. They found the source of the problem and fixed it.
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.
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.
Thought this was going to be about Gusto "remember this device" which keeps failing. Reported like 2 years ago
Error code 5, on Windows, means that the code tried to dereference a null pointer. I'm guessing that the GIF content is corrupt, containing some 0x00 bytes where they shouldn't be. Then the question becomes, whose responsibility is it to program defensively against things like that? If, as may well be, Chrome is using some third-party library nested several layers deep to render GIFs, then would there be any action that the chrome devs could take, aside from replacing that library with a better one and adding a malformed-GIF test case? (Why don't they already have a malformed-GIF test case...?)
Lets be honest, it was probably some grammarly .dll that had been injected...
Considering they’re trying Safari I suspect they’re on macOS.
Interesting advertisment, but not really a tech article.
Wrong article?
> Unfortunately, with access to neither the Chrome source code
I mean, you basically do! You can just go check out the chromium source.
> 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.
Google provides symbols for Chrome release builds, including source indexing so source code should be available. See sections symbol server and source indexing at https://www.chromium.org/developers/how-tos/debugging-on-win...
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.
Only for Windows. For some reason they don’t make their symbols for Mac public…
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.
Twirly prompts have sucked, for weird reasons, since the WWIV BBS days.
I guess some things never change.