Der seltsamste Bug, den ich bisher gesehen habe

Entdeckung und Behebung eines seltsamen Bugs

• Während des On-Call-Dienstes des internen Tool-Teams kam es bei Nutzern der internen Software von Gusto zu Browser-Abstürzen in Chrome.
• Das Problem verursachte vielfältige Störungen im Kundenservice.
• Zur Lösung des Problems wurde die Hilfe erfahrener Kollegen, des Produktinfrastruktur-Teams und des IT-Teams hinzugezogen.

Der erste Hinweis

• Es wurde versucht, Gemeinsamkeiten unter den betroffenen Nutzern zu finden.
• Nicht alle Gusto-Mitarbeitenden waren betroffen, und die kundenseitige Software funktionierte ohne Probleme.
• Andere Webseiten der internen Software funktionierten normal.
• Die Abstürze traten uneinheitlich auf, und in Safari oder Firefox trat das Problem nicht auf.

Der zweite Hinweis

• Es wurde die Hypothese aufgestellt, dass die Chrome-Version das Problem sein könnte.
• Bei einigen Nutzern schien das Problem nach einem Update ihrer Chrome-Version behoben zu sein, vollständig gelöst war es jedoch nicht.
• Es wurde vermutet, dass eine Chrome-Erweiterung die Ursache sein könnte, doch das Problem ließ sich auch ohne Erweiterungen reproduzieren.

Schwierigkeiten bei der Reproduktion des Bugs

• Das Infrastruktur-Team bat alle Engineers, das Problem zu reproduzieren.
• Mit Ausnahme von zwei Engineers in der Türkei meldete niemand aus dem Engineering-Team Abstürze.
• Die Chrome-Absturzberichtsfunktion war aus Sicherheitsgründen deaktiviert, was die Fehlersuche erschwerte.

Eine glückliche Wendung

• Ein Engineer in Denver meldete, dass das Problem auftrat, nachdem er die Desktop-App von Grammarly heruntergeladen hatte.
• Es wurde festgestellt, dass das Problem verschwand, wenn die Grammarly-App gelöscht und der Computer neu gestartet wurde.

Fortschritt

• Nachdem Debugging möglich geworden war, wurden verschiedene Versuche unternommen, um die Ursache des Problems zu finden.
• Die wichtigste interne Anwendung war auf ActiveAdmin aufgebaut, doch neuere Bereiche mit React stürzten nicht ab.
• Bei der Untersuchung gemeinsamer Codebestandteile wurde festgestellt, dass das Dropdown-Menü „My History“ die Ursache des Problems war.

Problemlösung

• Es wurde bestätigt, dass die Bilddatei loader-spinner.gif das Problem verursachte.
• Nachdem dieses GIF durch ein anderes Bild ersetzt worden war, stürzte die Seite nicht mehr ab.
• Ob Grammarly oder Chrome das Problem inzwischen behoben hat, ist unklar; jedenfalls bringt das ursprüngliche GIF Chrome nun nicht mehr zum Absturz.

Fazit

• Ein unerwartetes animiertes GIF war der Schlüssel zur Fehlersuche.
• Das Problem wurde durch Neugier und Zusammenarbeit gelöst.
• Gusto bietet die Möglichkeit, mit kooperativen und neugierigen Menschen zusammenzuarbeiten.

Meinung von GN⁺

Das Wichtigste an diesem Artikel ist die detaillierte Beschreibung, wie ein Bug mit einer unerwarteten Ursache entdeckt und behoben wurde. Der Text zeigt die Komplexität und Unvorhersehbarkeit des Software-Engineerings und betont, wie wichtig Teamwork und beharrliche Problemlösung sind. Er bietet ein spannendes Beispiel dafür, wie ein Engineering-Team gemeinsam ein rätselhaftes Problem löst, und dürfte für Menschen mit Interesse am Engineering ein äußerst ansprechender Beitrag sein.

[GN⁺]

Hacker-News-Kommentare

• Beim Lesen dachte ich, dass es vielleicht ein Grammarly-Problem sein könnte, denn ich hatte früher einmal einen ähnlichen Bug, der sich nicht reproduzieren ließ, aber viele Menschen innerhalb einer bestimmten Abteilung betraf
  Am Ende war die Gemeinsamkeit, dass die Grammarly-Erweiterung installiert war, und es trat nicht auf der Live-Seite auf, sondern nur auf einer Staging-Vorschau-URL
  Die Ursache war ein fehlerhafter regulärer Ausdruck in der Grammarly-Erweiterung, und wenn der Domainname ungefähr 100 Zeichen überschritt, fror die Seite ein
  Falls dieser Fall hier wirklich von der Desktop-App verursacht wurde, wirkt das noch beunruhigender

  • Ich war enttäuscht, dass die Geschichte mit „Wir können nicht in Grammarly oder Chrome hineinschauen, also wissen wir nicht, warum GIF-Decoding/Rendering den Crash verursacht“ endet
    Viele Probleme lassen sich auf eine bestimmte Kombination eingrenzen, aber wenn man nicht weiß, warum, ist es letztlich unbefriedigend
  • Ich habe heute wieder einen regulären Ausdruck debuggt, bei dem ein Nutzer durch falsche Werte in einem Formular das Backend in einen Denial-of-Service-Zustand versetzen konnte
    Deshalb lese ich gerade über Regex-Engines: https://swtch.com/%7Ersc/regexp/regexp1.html
  • Vor etwa fünf Jahren hatte ich etwas Ähnliches mit einer webbasierten Videoüberwachungssoftware
    Während eines unternehmensweiten Upgrades auf Windows 10 wurde der alte Laptop eines Managers ersetzt, und die Abläufe waren sauber organisiert: Prüfung der Software- und Netzwerkanforderungen, Backup des Benutzerprofils und der Dokumente usw.
    Auf dem Gerätebewertungsbogen stand, dass es ein 10 Jahre altes ThinkPad mit 4 GB RAM war und dass es ausging, sobald man das Stromkabel zog; angesichts dessen wirkte seine Geduld bemerkenswert
    Nach der Ausgabe des neuen Laptops funktionierte fast alles normal, nur die Übertragung der Grammarly-Lizenz nicht, also wurde dafür ein Ticket erstellt, und eine Woche später war der Lizenzschlüssel eingespielt und Grammarly als funktionierend bestätigt
    Später an diesem Tag kam dann die Meldung, dass die Webseite der Sicherheitskameras abstürze, und der Helpdesk hatte bereits Neustarts, Cache-Löschung, Browser-Neuinstallation und sogar ein neues Profil versucht, ohne Erfolg, also landete es bei mir
    Ich prüfte Netzwerk, Firewall-Logs, andere PCs sowie Zugriff vor Ort und von extern, aber bei mir funktionierte alles normal und sonst hatte niemand Probleme
    Als ich fragte, ob sich kürzlich etwas am PC oder im Büro geändert habe, sagte er halb im Scherz: „Ich habe heute Grammarly installiert, vielleicht daran?“ Da mir die Ideen ausgingen, haben wir es tatsächlich deinstalliert, und dann funktionierte es
    Nachdem wir Grammarly wieder aktiviert und auf den Link geklickt hatten, trat der Fehler zuverlässig erneut auf
    Diese Kamerasoftware war uralt, und die angepassten Startseiten-Links sahen wie extrem lange, von PHP erzeugte URLs aus; da vor Ort nur diese eine Person Grammarly nutzte, zeigte sich das Problem genau ein einziges Mal
  • Wenn sich ein Website-Bug nicht leicht lösen lässt, sollte der erste Schritt sein, alle Erweiterungen zu deaktivieren
    Entwickler vergessen oft, dass Erweiterungen die Ursache sein könnten, aber Erweiterungen können auf Webseiten die seltsamsten Dinge tun

• Ein Uni-Professor schrieb an einer wissenschaftlichen Arbeit und meinte, Unterstreichungen blieben nicht erhalten; ich dachte, das sei ein einfacher Bedienfehler und ich wäre in fünf Minuten fertig
  Tatsächlich dauerte es über drei Stunden, bis ich herausfand, dass nur die Kombination aus einer bestimmten Videokartentreiber-Version und einer bestimmten Druckertreiber-Version das Drucken von Unterstreichungen verhinderte

  • Immer noch besser als der Xerox-Bug, der Zahlen in gescannten Dokumenten veränderte
    https://www.zdnet.com/article/xerox-scanners-alter-numbers-i...
  • Ich frage mich, wie man so eine eigenartige Kombination in ungefähr drei Stunden überhaupt finden konnte
  • Ich verstehe nicht, wie eine Videokarte die Ausgabe beim Drucken beeinflussen kann

• Selbst wenn Crash-Reporting deaktiviert ist, könnte irgendwo im Benutzerprofilverzeichnis trotzdem eine .dmp-Datei erzeugt worden sein
  Wenn man diese Datei manuell an einen Bug unter https://crbug.com/new anhängt, können Chrome-Entwickler sie debuggen
  Falls man den Dump aus ähnlichen Gründen nicht teilen kann, aus denen auch das Crash-Reporting deaktiviert wurde, kann man in Chromium minidump_stackwalk bauen, einen Stacktrace ohne Symbole erzeugen und ihn an den Bug anhängen
  Dann können die Chrome-Entwickler die Symbole dazu auflösen
  Mehr dazu steht unter https://www.chromium.org/developers/decoding-crash-dumps/

• Die technische Kombination hinter diesem Bug ist faszinierend. Genau so sieht das Web des Jahres 2023 aus
  Ich würde gern wissen, ob der Chromium-Bug behoben wurde, aber diese Liste ist nicht leicht zu durchsuchen: https://bugs.chromium.org/p/chromium/issues/list?can=1&q=gif...
  Mir gefällt auch der Eindruck, dass Gusto diesen Beitrag veröffentlicht hat, um zu zeigen: „Es war nicht unser Fehler“, und dabei Grammarly noch einen kleinen Seitenhieb mitzugeben

  • Da das Problem nicht nach außen sichtbar war, wirkt es weniger wie eine Frage der Verantwortung als einfach wie eine interessante Geschichte, die zugleich kostenlose Werbung ist
  • Dieses GIF muss unbedingt veröffentlicht werden
  • Vielleicht war es auch dieses Problem hier: https://bugs.chromium.org/p/chromium/issues/detail?id=129770...

• Es gab gelegentlich ein Problem, dass nach dem Booten von Linux kein Ton zu hören war; wie sich herausstellte, hing das mit der Windows-Dual-Boot-Konfiguration zusammen.
  Wenn man aus Windows neu startete, wurde das Realtek-Audiogerät nicht vollständig ausgeschaltet, sondern nur in einen Ruhezustand versetzt, und Linux konnte das Gerät dann nicht initialisieren.
  Die einzige Lösung war, Windows immer vollständig herunterzufahren und dann per Einschaltknopf wieder zu starten; das Problem besteht aber weiterhin: https://askubuntu.com/questions/1032543/no-sound-in-ubuntu-1...

  • Ich habe auch einen fast umgekehrten Fall gesehen.
    Bei jemandem mit Windows- und Linux-Dual-Boot funktionierte das WLAN nur, wenn nach dem Booten in Windows von dort aus nach Linux neu gestartet wurde.
    In der Linux-Installation fehlte das Firmware-Paket für die WLAN-Karte; beim Neustart aus Windows war das Gerät daher bereits vorbereitet, bei einem direkten Kaltstart in Linux jedoch nicht.
  • Ähnliches gab es auch in der anderen Richtung: Nach einem Neustart aus Linux zeigte Windows 10 während des Bootens einen Blue Screen.
  • Ich frage mich, ob das Deaktivieren des Schnellbenutzerwechsels das auch nicht gelöst hat.
  • Vor einigen Jahren habe ich ein ähnliches Verhalten auch schon bei Bluetooth-Geräten gesehen.

• Ich stimme zu, dass das Ende eine ziemliche Enttäuschung ist.
  Da weder auf den Chrome-Quellcode noch auf den Grammarly-Quellcode zugegriffen werden kann, bleibt es bei Vermutungen; ich frage mich, ob das ein Ergebnis der „Open-Source“-Bewegung ist.
  Ohne Quellcode gibt es nun Entwickler, die völlig die Orientierung verlieren und sich weigern, tiefer zu graben, und aus Sicht von Unternehmen, die die Wahrheit lieber nicht offenlegen wollen, ist so eine Haltung natürlich sehr willkommen.
  Früher gab es viele Leute, die Programme auch ohne Quellcode disassemblierten, verstanden und patchten, und viele von ihnen waren nicht einmal professionelle Entwickler.
  Sie wollten einfach nur Software dazu bringen, sich so zu verhalten, wie sie es wollten, und haben dabei ganz natürlich so viel gelernt, wie nötig war.
  Der Artikel streift auch, wie wahnsinnig komplex der gesamte Stack geworden ist. Wenn man sieht, wie sich Framework auf Framework stapelt, fühlt sich ein guter Teil davon selbst verschuldet an.
  Dass der Seitenabsturz aufhörte, nachdem loader-spinner.gif, also der Platzhalter während des Ladens der Menüoptionen, entfernt wurde, wirft auch die Frage auf, warum das Laden von Menüoptionen überhaupt lange genug dauert, um eine Animation zu brauchen.

  • Zu erwarten, dass alle Entwickler Binärdateien patchen können, ist höflich gesagt unrealistisch.
    Die Welt des Software Engineering ist enorm weit, und alle Teile des Stacks zu kennen, ist schon seit Langem nahezu unmöglich.
    Außerdem ist Software Engineering eine Lernreise, und jeder befindet sich auf einem anderen Punkt dieser Reise.
  • Selbst wenn Open Source vorhanden ist, scheint es insgesamt an Bereitschaft zu fehlen, den Code tatsächlich zu lesen.
    Vom Öffnen eines Disassemblers oder dem Anhängen eines Debuggers ganz zu schweigen; solche Fähigkeiten werden heutzutage offenbar kaum noch gelehrt.
  • Wahrscheinlich wird eine Netzwerkanfrage gestellt, um die Menüoptionen zu holen.
    Normalerweise ist das fast sofort erledigt, aber für den Fall, dass es länger dauert, ist ein Loading Spinner durchaus sinnvoll.

• Das Seltsamste war ein Fall, in dem sich bei einem bestimmten Formular der eingegebene Text nach dem Speichern veränderte.
  Zuerst dachte ich, jemand anderes würde dasselbe Formular gleichzeitig bearbeiten, aber laut Logs war das nicht so, und auf meinem Rechner wurde der richtige Text angezeigt.
  Dann fiel mir auf einem Screenshot auf, dass auch einige Menütexte merkwürdig waren, und die Ursache war, dass in Chrome die Option „Diese Seite übersetzen“ aktiviert war.
  Nachdem ich erklärt hatte, wie man die Sprache korrekt innerhalb der App wechselt, verschwand das Problem.

  • Nachdem wir einen Bug entdeckt hatten, bei dem Chrome die Seite kaputtmacht, haben wir die entsprechende Einstellung auf allen Seiten unserer Single-Page-Webapp ergänzt.
    Das scheint jetzt die neue Ordnung zu sein, die man auf Apps oder Elemente anwenden kann. Vermutlich ist es nicht per CSS, weil man keine dynamischen Änderungen unterstützen wollte, und hübsch sieht es auch nicht aus: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
    Manchmal schaut man sich die Meta-Tags großer Single-Page-Apps an und entdeckt auf der Suche nach dem Grund für ein Tag ein neues Grauen.
  • Das ist wirklich nervig.
    Beim Lesen japanischer Websites bin ich oft auf Google Translate angewiesen, aber jede Website mit React geht kaputt,
    weil React und Google Translate beide nichts voneinander wissen und DOM-Knoten aktualisieren wollen.
    Ich habe mir sogar einmal ernsthaft die Implementierung von Google Translate angesehen, um später vielleicht ein Web-Widget ohne dieses Problem nachbauen zu können.
    [1] https://bugs.chromium.org/p/chromium/issues/detail?id=872770
  • Ich frage mich, ob da Englisch ins Amerikanische übersetzt wurde oder was auch immer.
  • Diese Geschichte ist so komisch, dass man sie auch an DaylyWTF schicken könnte.

• Ein allzu vertrautes Problem.
  Früher habe ich gesehen, wie die Barrierefreiheitstools von Chrome in Dropdown-Menüs solche Probleme verursachten, und das ließ sich schon mit sehr wenig HTML reproduzieren.
  Der konkrete Bug, über den ich vor zwei Jahren gestolpert bin, trat zwar in Chromium-Edge auf, aber Symptom und Ursache waren sehr ähnlich.
  Grammarly verlässt sich mit ziemlicher Sicherheit auf einen Teil der Barrierefreiheitstools von Chrome.
  Solche Tools unterscheiden sich leicht zwischen Chromium-basierten Browsern wie Edge, Brave und Chrome.

  • Wenn diese Hypothese stimmt, heißt das dann, dass Grammarly Desktop das GIF sieht, irgendwie Browser-Barrierefreiheitsfunktionen aufruft und Chrome dabei abstürzt, weil es das nicht verarbeiten kann?

• Wenn so etwas das nächste Mal passiert, würde ich einfach empfehlen, einen anderen Browser zu verwenden.
  Vor allem Firefox ist inzwischen deutlich besser darin, Lesezeichen, Passwörter und Ähnliches aus Chrome zu importieren.
  Das Universum hat jetzt ein Signal gesendet, dass es Zeit zum Wechseln ist, und wir können dieses Signal nicht ignorieren.
  Übrigens bin ich Firefox-Ingenieur, aber das hat mit diesem Rat überhaupt nichts zu tun.

  • Aus Ingenieurssicht ist Firefox definitiv eine gute Lösung.
    Aus PM-Sicht denkt man sich eher: Wir haben vier Monate darauf verwendet, das Onboarding zu vereinfachen, und jetzt sollen wir den Leuten sagen, sie sollen einen neuen Browser installieren?
  • Im verlinkten Artikel ist das bereits ausdrücklich als Workaround genannt.
  • Chrome hat mehr als die Hälfte des Markts.
    Wenn ein browserbasiertes Produkt im weltweit meistgenutzten Browser nicht richtig funktioniert, ist das kein gutes Zeichen.

• Aus Sicherheitsgründen Chrome-Absturzberichte zu blockieren, während Mitarbeitende Grammarly installieren dürfen, ist wirklich eine Unternehmenssicherheitsrichtlinie ganz nach meinem Geschmack