The weirdest bug I've seen yet

https://engineering.gusto.com/the-weirdest-bug-ive-seen-yet/

by jevans • 3 years ago

619 308 3 years ago

engineering.gusto.com

wobblyasp• 3 years ago

Such a tease. At least upload the gif so people can poke at it!

yuck39• 3 years ago

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?

hyperhello• 3 years ago

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!

fifafu2• 3 years ago

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.

12_throw_away• 3 years ago

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.

0xNotMyAccount• 3 years ago

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.

Andrex• 3 years ago

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.

robocat5• 3 years ago

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

tclancy• 3 years ago

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.

Maxion• 3 years ago

I feel so unsatisfied

fifafu2• 3 years ago

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.

chrismorgan2• 3 years ago

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.

sfink4• 3 years ago

more like a murder weapon

azlev• 3 years ago

Hash collision?

sapiogram• 3 years ago

What?

tru3_power• 3 years ago

Is there a copy of the gif available? That’s interesting

digging• 3 years ago

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.

guessmyname• 3 years ago

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

[3] http://hexfiend.com

[4] https://github.com/HexFiend/HexFiend/blob/master/templates/I...

[5] https://www.synalysis.net

dblitt• 3 years ago

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.

roozbeh18• 3 years ago

haha, that was questionable for me as well. It's ok for Grammarly to read your stuff, but crash metadata is a no no.

JohnMakin4• 3 years ago

Welcome to security in 2023 :)

madeofpalk• 3 years ago

Unfortunately, with access to neither the Chrome source code

I mean, you basically do! You can just go check out the chromium source.

flutas• 3 years ago

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.

j1mmie2• 3 years ago

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.

orbv• 3 years ago

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

simion3142• 3 years ago

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.

LgWoodenBadger• 3 years ago

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?

simion3142• 3 years ago

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)

saagarjha9• 3 years ago

Most bugs are software issues, though.

lloydatkinson• 3 years ago

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.

j1mmie2• 3 years ago

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

thenoblesunfish• 3 years ago

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.

nonethewiser7• 3 years ago

They should definitely publish the gif

j16sdiz• 3 years ago

Something like this https://bugs.chromium.org/p/chromium/issues/detail?id=129770...

computerfriend• 3 years ago

If they can figure it out, they're sitting on potentially a very valuable exploit.

jdminhbg2• 3 years ago

One that's been patched already, though, as they say that in current versions of Chrome and Grammarly it doesn't crash.

chatmasta3• 3 years ago

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 ;)

saulpw2• 3 years ago

It wasn't the Grammarly extension, it was the desktop app.

Sophira• 3 years ago

I'd also be interesting in seeing the raw .gif file - as a hobbyist wannabe researcher myself, I'd love to investigate this.

Modified3019• 3 years ago

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

barbegal• 3 years ago

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.

whirlwin• 3 years ago

Shared library like libgif used by both Chrome and Grammarly but different versions?

JohnMakin4• 3 years ago

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.

bicijay• 3 years ago

But you may have

lbhdc• 3 years ago

Ahhh, Schrodinger's patch.

gwbas1c3• 3 years ago

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.

JohnMakin4• 3 years ago

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.

tetha2• 3 years ago

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"

saulpw2• 3 years ago

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.

derefr2• 3 years ago

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.

nonethewiser7• 3 years ago

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.

nonethewiser7• 3 years ago

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.

JohnMakin4• 3 years ago

Maybe, but they don’t know another GIF couldn’t eventually cause the same issue again.

djbusby• 3 years ago

Thought this was going to be about Gusto "remember this device" which keeps failing. Reported like 2 years ago

sonicanatidae• 3 years ago

Twirly prompts have sucked, for weird reasons, since the WWIV BBS days.

I guess some things never change.

zwieback• 3 years ago

Left me hanging, would not post something like this from my engineering blog. They don't have deeep debugging skills at gusto?

golergka• 3 years ago

Sounds like they have good time management and prioritisation skills. They found the source of the problem and fixed it.

KerrAvon• 3 years ago

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.

dhritzkiv• 3 years ago

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

cyco1303• 3 years ago

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.

bee_rider• 3 years ago

What was translating from English to American or something?

cyco1303• 3 years ago

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.

robocat5• 3 years ago

I added

  <meta name="google" content="notranslate">

to all pages in a single-page-web-app after discovering some bug or other with Chrome screwing up the page.

Apparently the new incantation to fix an app (can be applied to an element) is (ugly: I presume it isn't CSS to avoid supporting dynamically changing it):

  <html translate="no">

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

Every now and then I would look at the meta tags for a major single page app and discover some new horror when searching for the reason for the meta tag!

michaelcampbell• 3 years ago

I know what you mean, but this caused me a second of "wait, what?"

all pages in a single-page-web-app

jonathrg• 3 years ago

    <html translate="no">

I first read this as "translate to Norwegian"

cyco1303• 3 years ago

I wouldn't want to disallow translation, but in this case it was unnecessary anyway.

lifthrasiir• 3 years ago

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

NooneAtAll3• 3 years ago

you should submit this story to DaylyWTF or smth

it's hilarious

jrockway• 3 years ago

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.

tedivm• 3 years ago

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.

bayindirh• 3 years ago

Maybe adding Grammarly created enough of a lag causing the GIF file to be shown?

AnimalMuppet• 3 years ago

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.

user3939382• 3 years ago

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.

nudgeee• 3 years ago

Vapor lock. Legend here: https://www.snopes.com/fact-check/cone-of-silence/

RajT88• 3 years ago

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.

superfrank• 3 years ago

Up there with the "I can't send an email over 500 miles" story

https://web.mit.edu/jemorris/humor/500-miles

suzzer99• 3 years ago

I love this one so much.

gostsamo• 3 years ago

This one is a legend. I love it, but you can find the debunking on the fact checking sites.

trehalose• 3 years ago

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?

mgaunard• 3 years ago

The main reason for tabs to crash is running out of RAM.

Never do you see the guy investigating memory usage, which is weird.

marcellus23• 3 years ago

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.

gwbas1c3• 3 years ago

If that were the case, I think the bug would be much easier to reproduce; and be a lot more widespread.

neilv3• 3 years ago

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)?

Zetobal• 3 years ago

Maybe they have the enterprise licence with grammarlys pinky swear that they won't train on your data.

hilux• 3 years ago

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

EdwardDiego2• 3 years ago

Holy hell lol.

realmike33• 3 years ago

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.

neilv3• 3 years ago

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

Etheryte• 3 years ago

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.

ncann• 3 years ago

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.

gwbas1c3• 3 years ago

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.

neilv3• 3 years ago

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.")

kube-system2• 3 years ago

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.

MattDaEskimo2• 3 years ago

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.

lobf• 3 years ago

You must not have read the article because he literally addresses this.

mplewis3• 3 years ago

*She – the author’s name is Amy

mplewis3• 3 years ago

You really want to change an entire company’s mandated browser every time a bug causes a problem with an extension?

nabakin• 3 years ago

They say in the article that the bug became a much lower priority because their employees simply switched browsers

cristeigabriel2• 3 years ago

Maybe Grammarly doesn't work for Chromium? (guessing)

1123581321• 3 years ago

How could you write all this and not post the gif so we can try it?

andrewfromx• 3 years ago

oh and there's this one: https://web.mit.edu/jemorris/humor/500-miles

tgsovlerkhgsel• 3 years ago

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.

ljm• 3 years ago

I was hoping for a bit more of a payoff. Like, if the gif was broken, why did the grammarly extension trigger it reliably?

jiveturkey3• 3 years ago

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.

saagarjha9• 3 years ago

GIFs don’t get automatically converted to webp files.

jiveturkey3• 3 years ago

says who? any web server (nginx, whatever) can be told to do this

romanhn• 3 years ago

Another favorite bug investigation of you're into this sort of thing: https://www.pagerduty.com/blog/the-discovery-of-apache-zooke...

ecshafer• 3 years ago

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.

eichin• 3 years ago

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

_jal• 3 years ago

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.

ryandrake• 3 years ago

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.

generationP3• 3 years ago

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?

natbennett2• 3 years ago

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.

ianlevesque• 3 years ago

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.

Muromec• 3 years ago

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.

thaumaturgy3• 3 years ago

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

mardifoufs5• 3 years ago

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.

akira2501• 3 years ago

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.

NautilusWave2• 3 years ago

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

mckn1ght• 3 years ago

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

CobrastanJorji• 3 years ago

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.

Szpadel• 3 years ago

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

bongodongobob4• 3 years ago

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.

ozr• 3 years ago

I really like Grammarly as a product, but I exclusively use their web editor. I wonder what their web vs desktop usage is.

mrweasel• 3 years ago

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.

hartator• 3 years ago

Maybe the name was odd `loader-spinner.gif`

FrankWilhoit• 3 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...?)

londons_explore• 3 years ago

Lets be honest, it was probably some grammarly .dll that had been injected...

saagarjha9• 3 years ago

Considering they’re trying Safari I suspect they’re on macOS.

Night_Thastus• 3 years ago

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!

sethammons• 3 years ago

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

ja5087• 3 years ago

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.

bluesmoon• 3 years ago

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.

rvanlaar• 3 years ago

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

https://github.com/microsoft/vscode-python/issues/9216

boringuser2• 3 years ago

The blink debug logs would probably be pretty useful for the engineers involved...

rootsudo• 3 years ago

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

crazygringo• 3 years ago

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.

saagarjha9• 3 years ago

This would be strange since macOS should not let Chrome load libraries that aren’t signed by Google.

masswerk• 3 years ago

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?

mike_hearn• 3 years ago

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.

hcrean• 3 years ago

I wonder if they checked for exploit code in the image the they likely originally found somewhere on Google.

toddmorey3• 3 years ago

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.

generationP3• 3 years ago

Huh? How does a video card affect printing?

jfoutz• 3 years ago

A lot of rendering will go through the video card if available, like the jvm does this as an optimization.

shever73• 3 years ago

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.

to11mtm• 3 years ago

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.

issung• 3 years ago

How does one discover something that niche in ~3 hours?

toddmorey3• 3 years ago

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.

29athrowaway• 3 years ago

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

b3lvedere• 3 years ago

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.

nialv7• 3 years ago

I feel the author might have missed out on a multi-thousand dollar bug bounty.

aaaronic2• 3 years ago

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

nonethewiser7• 3 years ago

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?

saagarjha9• 3 years ago

Perhaps it has an extension that it installs that does this?

aaaronic2• 3 years ago

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.

gelatocar• 3 years ago

As 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!

codethief2• 3 years ago

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

dev_slash_null• 3 years ago

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

beaugunderson• 3 years ago

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

karmakaze2• 3 years ago

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.

chatmasta3• 3 years ago

It would be nice if the author would at least publish the .gif file. I want to dig into this.

jsunderland323• 3 years ago

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.

jolux2• 3 years ago

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.

bongodongobob4• 3 years ago

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.

leptons2• 3 years ago

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.

SonOfLilit2• 3 years ago

This is not an extension. It's some other kind of plugin or weird hook. They tried disabling all extensions first thing.

aquafox• 3 years ago

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

nightfly• 3 years ago

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.

sodality2• 3 years ago

This is my exact problem with a HP envy X360. HP refuses to fix the bug in BIOS. :/

https://bugzilla.redhat.com/show_bug.cgi?id=2107845

genpfault• 3 years ago

Had the same thing going the other way: rebooting from Linux caused Windows 10 to bluescreen during boot.

trinsic2• 3 years ago

turning off fast user switching didnt fix it?

roflmaostc• 3 years ago

once observed similar behavior with my bluetooth device years ago.

sfink4• 3 years ago

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

OsrsNeedsf2P• 3 years ago

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?

noizejoy• 3 years ago

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.

Shaanie• 3 years ago

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.

mplewis3• 3 years ago

This is explicitly stated as a workaround in the linked article.

langsoul-com• 3 years ago

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

denton-scratch• 3 years ago

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!

lantry• 3 years ago

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"

CGamesPlay• 3 years ago

I love the corporate security policy that disables Chrome crash reporting for security reasons, but allows employees to install Grammarly.

NautilusWave2• 3 years ago

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.

numitus• 3 years ago

Interesting advertisment, but not really a tech article.

EdwardDiego2• 3 years ago

Wrong article?

resonious• 3 years ago

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.

eyelidlessness• 3 years ago

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.

randshift• 3 years ago

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.

sanderjd• 3 years ago

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.

karim79• 3 years ago

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

alpb• 3 years ago

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.

alexeldeib• 3 years ago

They allegedly tried chromium without luck.

Sxubas• 3 years ago

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.

robocat5• 3 years ago

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.

flippinfloppin• 3 years ago

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!

userbinator2• 3 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?

hmry• 3 years ago

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.

windowsworkstoo• 3 years ago

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

cyclotron3k• 3 years ago

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.

andershaig• 3 years ago

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

DaleCurtis• 3 years ago

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.

LASR• 3 years ago

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.

1letterunixname• 3 years ago

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.

slavboj• 3 years ago

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.

jtokoph• 3 years ago

It’s hard blocked on any corporate devices where I work.

fijiaarone• 3 years ago

Ah, Tsutomo, my learned disciple!

jongjong2• 3 years ago

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.

jongjong2• 3 years ago

Update: After writing this comment, me and my wife started getting Grammarly ads. Awful.

socketcluster• 3 years ago

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.

KevinMS• 3 years ago

https://en.wikipedia.org/wiki/Heisenbug

ghosty141• 3 years ago

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.

hrtk• 3 years ago

Can you share the `loader-spinner.gif` ? Preferably over a service that does not recompress it.

65102• 3 years ago

   alert(banana++)

Should lock things up and not continue until OK is clicked.

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.

jspaetzel• 3 years ago

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.

cristeigabriel2• 3 years ago

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.

bradley13• 3 years ago

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

jon-wood• 3 years ago

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?

jaggirs• 3 years ago

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.

SonOfLilit2• 3 years ago

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.

butz• 3 years ago

And that's yet another reason that we must have several different browser engines.

Fanmade• 3 years ago

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

c0ndu17• 3 years ago

Honourable mention, “we can’t send emails more than 500 miles” https://web.mit.edu/jemorris/humor/500-miles

The weirdest bug I've seen yet

Related Stories