Şimdiye Kadar Gördüğüm En Garip Bug

 (engineering.gusto.com)
1 puan yazan GN⁺ 2023-12-01 | 1 yorum | WhatsApp'ta paylaş

Garip bir bug'ın keşfi ve çözüm süreci

  • İç araçlar ekibinde nöbet sırasında, Gusto'nun iç yazılımını kullanan kullanıcılar Chrome tarayıcısının çökmesi sorununu yaşadı.
  • Bu sorun müşteri hizmetlerinde çeşitli aksamalara yol açtı.
  • Sorunu çözmek için deneyimli ekip arkadaşlarından, ürün altyapısı ekibinden ve BT ekibinden yardım alındı.

İlk ipucu

  • Etkilenen kullanıcılar arasında ortak bir nokta bulunmaya çalışıldı.
  • Tüm Gusto çalışanları etkilenmedi ve müşteriyle doğrudan temas eden yazılımlarda sorun yoktu.
  • Diğer iç yazılım web sayfaları normal çalışıyordu.
  • Çökme tutarsız biçimde meydana geliyor ve Safari ya da Firefox'ta sorun yaşanmıyordu.

İkinci ipucu

  • Sorunun Chrome sürümünden kaynaklanıyor olabileceği varsayıldı.
  • Bazı kullanıcılar Chrome sürümünü güncellediğinde sorun çözülmüş gibi görünse de tamamen ortadan kalkmadı.
  • Chrome uzantılarının sebep olabileceği düşünüldü, ancak uzantılar olmadan da sorun yeniden üretilebildi.

Bug'ı yeniden üretmenin zorluğu

  • Altyapı ekibi tüm mühendislerden sorunu yeniden üretmelerini istedi.
  • Türkiye'deki iki mühendis dışında mühendislik ekibinden çökme bildirimi gelmedi.
  • Chrome'un çökme raporlama özelliği güvenlik nedeniyle devre dışı olduğundan sorun çözme süreci zorlaştı.

Şanslı dönüm noktası

  • Denver'daki bir mühendis, Grammarly masaüstü uygulamasını indirdikten sonra sorunun ortaya çıktığını bildirdi.
  • Grammarly uygulaması silinip bilgisayar yeniden başlatıldığında sorunun düzeldiği görüldü.

İlerleme

  • Debugging mümkün hale gelince, sorunun kök nedenini bulmak için çeşitli denemeler yapıldı.
  • Ana iç uygulama ActiveAdmin tabanlıydı, ancak React kullanan yeni bölümler çökmüyordu.
  • Ortak kod bölümleri incelenirken, My History açılır menüsünün sorunun kaynağı olduğu bulundu.

Sorunun çözümü

  • loader-spinner.gif görsel dosyasının soruna yol açtığı doğrulandı.
  • Bu GIF başka bir görselle değiştirildiğinde sayfa artık çökmüyordu.
  • Sorunu Grammarly'nin mi yoksa Chrome'un mu çözdüğü belirsiz olsa da, artık orijinal GIF Chrome'u çöktürmüyor.

Sonuç

  • Beklenmedik bir animasyonlu GIF, debugging sürecinin cevabı oldu.
  • Sorun merak ve iş birliği sayesinde çözüldü.
  • Gusto, iş birliğine açık ve meraklı insanlarla birlikte çalışma fırsatı sunuyor.

GN⁺'ın görüşü

Bu yazıdaki en önemli nokta, beklenmedik bir nedenden kaynaklanan bir bug'ın nasıl bulunup çözüldüğünün ayrıntılı biçimde anlatılması. Yazı, yazılım mühendisliğinin karmaşıklığını ve öngörülemezliğini gösterirken ekip çalışmasının ve ısrarlı problem çözme becerisinin ne kadar önemli olduğunu vurguluyor. Mühendislik ekibinin böylesine zor bir problemi birlikte nasıl çözdüğüne dair ilgi çekici bir örnek sunuyor; bu da onu mühendislik alanına ilgi duyanlar için oldukça çekici bir hikâye haline getiriyor.

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-01
Hacker News yorumları

  • Okurken bunun Grammarly ile ilgili bir sorun olabileceğini düşündüm; daha önce de benzer biçimde yeniden üretilemeyen ama belirli bir departman içindeki birçok kişiyi etkileyen bir hatayla karşılaşmıştım.
    Sonunda ortak noktanın Grammarly eklentisinin kurulu olması olduğu ortaya çıktı; sorun canlı sitede değil, yalnızca staging önizleme URL’sinde yaşanıyordu.
    Nedeni Grammarly eklentisindeki hatalı bir düzenli ifadeydi; alan adı yaklaşık 100 karakteri aşınca sayfa kilitleniyordu.
    Bu olay gerçekten masaüstü uygulaması yüzünden olduysa daha da korkutucu geliyor.

    • Sonunun “Grammarly’nin ya da Chrome’un içini göremediğimiz için GIF kod çözme/render işleminin neden çökerttiğini bilmiyoruz” diye bitmesi hayal kırıklığıydı.
      Birçok sorun belirli bir kombinasyona kadar daraltılıyor ama asıl nedenini bilmiyorsanız tatmin edici olmuyor.
    • Bugün de kullanıcı forma hatalı bir değer girince arka ucu hizmet dışı bırakabilecek bir düzenli ifadeyi debug ettim.
      Bu yüzden şu anda düzenli ifade motorunu okuyorum: https://swtch.com/%7Ersc/regexp/regexp1.html
    • Yaklaşık 5 yıl önce web tabanlı bir video gözetim yazılımında benzer bir şey yaşadım.
      Şirket genelinde Windows 10 yükseltmesi sırasında bir yöneticinin eski dizüstü bilgisayarını değiştirdik; yazılım ve ağ gereksinimlerini kontrol etme, kullanıcı profili ve belgeleri yedekleme gibi süreçler iyi oturmuştu.
      Donanım değerlendirme formunda 10 yıllık ThinkPad, 4 GB RAM ve güç kablosu çıkarılınca kapandığı notu vardı; o şekilde kullanmaya katlanması gerçekten büyük sabır gibi görünüyordu.
      Yeni dizüstü dağıtıldıktan sonra neredeyse her şey normaldi; sadece Grammarly lisansı taşınamamıştı, bunun için talep açıldı ve bir hafta sonra lisans anahtarı uygulanıp Grammarly’nin de düzgün çalıştığı doğrulandı.
      Ancak o günün ilerleyen saatlerinde güvenlik kamerası web sayfasının çöktüğüne dair haber geldi; yardım masası yeniden başlatma, önbelleği temizleme, tarayıcıyı yeniden kurma ve profili yeniden oluşturma dahil her şeyi denedi ama çözülmeyince konu bana aktarıldı.
      Ağı, güvenlik duvarı kayıtlarını, başka PC’leri, yerel/harici erişimi kontrol ettim; benim tarafımda her şey normaldi ve başka kimsede sorun yoktu.
      “Son zamanlarda PC’de ya da ofiste değişen bir şey oldu mu?” diye sorunca şaka yollu “Bugün Grammarly’yi kurdum, ondan mı acaba?” dedi; fikirlerim tükendiği için gerçekten kaldırmayı denedik ve çalıştı.
      Grammarly’yi tekrar açıp bağlantıya tıklayınca kesin olarak başarısız oldu.
      O kamera yazılımı çok eskiydi; özel ana sayfa bağlantısı PHP’nin ürettiği çok uzun bir URL’ye benziyordu ve sahada Grammarly kullanan tek kişi o olduğu için sorun yalnızca bir kez görülmüştü.
    • Bir web sitesi hatası kolay çözülmüyorsa ilk adım tüm eklentileri devre dışı bırakmak olmalı.
      Geliştiriciler sorunun eklentilerden kaynaklanabileceğini sık sık gözden kaçırıyor; oysa eklentiler web sayfalarında akla gelmedik işler yapabiliyor.

  • Üniversitede hocam bir makale yazarken alt çizginin kalıcı olmadığını söyledi; basit bir kullanıcı hatası sandım ve 5 dakikada yardım edebileceğimi düşündüm.
    Ama 3 saatten fazla süre sonra, belirli bir ekran kartı sürücüsü sürümü ile belirli bir yazıcı sürücüsü sürümü kombinasyonunun yalnızca alt çizgi çıktısını engellediğini bulabildim.

    • Taranmış belgelerdeki sayıları değiştiren Xerox hatasından daha iyi sayılır bence.
      https://www.zdnet.com/article/xerox-scanners-alter-numbers-i...
    • Böyle sıra dışı bir kombinasyonu yaklaşık 3 saatte nasıl bulduğunu merak ediyorum.
    • Ekran kartının çıktıyı nasıl etkileyebildiğini anlamıyorum.

  • Çökme raporlamasını kapatmış olsanız bile kullanıcı profili dizininde bir yerlerde .dmp dosyası oluşturulmuş olma ihtimali var.
    Bu dosyayı https://crbug.com/new üzerindeki bir hataya manuel olarak yüklerseniz Chrome geliştiricileri debug edebilir.
    Çökme raporunu kapatmanızla benzer nedenlerle dump dosyasını paylaşamıyorsanız Chromium’da minidump_stackwalk derleyip sembolsüz bir stack trace oluşturabilir ve hataya ekleyebilirsiniz.
    Böylece Chrome geliştiricileri sembolleri iliştirebilir.
    Ayrıntılar https://www.chromium.org/developers/decoding-crash-dumps/ adresinde.

  • Bu hatayı ortaya çıkaran teknoloji kombinasyonu ilginç. 2023’ün web’i tam olarak böyle bir şey.
    Chromium hatasının çözülüp çözülmediğini bilmek isterdim ama bu listede gezinmek kolay değil: https://bugs.chromium.org/p/chromium/issues/list?can=1&q=gif...
    Gusto’nun “bizim hatamız değildi”yi gösterirken Grammarly’ye hafifçe laf sokmak için bu yazıyı yayımlamış olması hissi de hoşuma gitti.

  • Linux ile önyükleme yaptıktan sonra bazen sesin gelmediği bir sorun vardı; meğer Windows çift önyükleme ayarlarıyla ilgiliymiş
    Windows’tan yeniden başlatınca Realtek ses aygıtını tamamen kapatmayıp yalnızca uyku durumunda bırakıyor, Linux da o aygıtı başlatamıyormuş
    Çözüm, Windows’ta her zaman kapatıp ardından güç düğmesine basarak açmaktan ibaretti; sorun hâlâ duruyor: https://askubuntu.com/questions/1032543/no-sound-in-ubuntu-1...

    • Buna neredeyse ters bir durum da görmüştüm
      Windows ve Linux’u çift önyüklemeyle kullanan biri, Wi-Fi’nin çalışması için önce Windows’a önyükleyip sonra Linux’a yeniden başlatmak zorundaydı
      Linux kurulumunda Wi-Fi kartı için firmware paketi yoktu; Windows’tan yeniden başlatınca aygıt zaten hazır durumda oluyordu ama doğrudan Linux’a soğuk önyükleme yapınca çalışmıyordu
    • Ters yönde de benzer bir şey olmuştu. Linux’tan yeniden başlatınca Windows 10 önyükleme sırasında mavi ekran veriyordu
    • Hızlı kullanıcı değiştirmeyi kapatmanın da çözüm olup olmadığını merak ediyorum
    • Birkaç yıl önce Bluetooth aygıtlarında da benzer bir davranış görmüştüm

  • Sonunun tamamen heves kırıcı olduğuna katılıyorum
    Chrome kaynak koduna da Grammarly kaynak koduna da erişemediğimiz için ancak tahmin yürütebiliriz deniyor; bunun “açık kaynak” hareketinin yarattığı sonuç olup olmadığını merak ediyorum
    Kaynak kod olmadan tamamen yolunu kaybeden ve daha derine inmeyi reddeden geliştiriciler ortaya çıkmış oldu; gerçeğin bilinmesini istemeyen şirketler açısından bu tavır oldukça memnuniyet verici olsa gerek
    Eskiden kaynak olmadan da programları disassemble edip anlayan ve patch’leyen çok kişi vardı; bunların önemli bir kısmı profesyonel geliştirici bile değildi
    Sadece yazılımı istedikleri gibi çalıştırma motivasyonları vardı ve bu süreçte doğal olarak ihtiyaç duydukları kadar öğreniyorlardı
    Bu yazı, tüm stack’in karmaşıklığının delirmiş olmasına da değiniyor. Framework üstüne framework’ün peş peşe geldiğini görünce bunun önemli bir kısmı insanın kendi başına açtığı iş gibi geliyor
    loader-spinner.gif, yani menü seçenekleri yüklenirken gösterilen yer tutucuyu kaldırınca sayfa çökmeleri durmuş; menü seçeneklerini yüklemenin animasyon gerektirecek kadar uzun sürüp sürmediği de ayrı bir soru

    • Her geliştiricinin binary patch’leyebilmesini beklemek, kibarca söylemek gerekirse gerçekçi değil
      Yazılım mühendisliği dünyası inanılmaz geniş ve stack’in her parçasını bilmek uzun zamandır neredeyse imkânsız hâle geldi
      Üstelik yazılım mühendisliği bir öğrenme yolculuğu ve herkes bu yolculuğun farklı bir noktasında
    • Açık kaynak olsa bile insanların gerçekten kodu okumaya yönelik iradesi genel olarak yetersiz görünüyor
      Disassembler açmak ya da debugger bağlamak şöyle dursun, bu tür beceriler artık pek öğretilmiyor gibi
    • Muhtemelen menü seçeneklerini almak için ağ isteği yapıyordur
      Genelde neredeyse anında bitse bile, uzun sürmesi ihtimaline karşı loading spinner koymak mantıklı

  • Bir kullanıcının belirli bir forma girdiği ifadenin kaydedince değiştiğini söylediği olay en tuhafıydı
    Başta aynı formu başka birinin aynı anda düzenlediğini sandım ama loglara göre öyle değildi; benim bilgisayarımda doğru ifade görünüyordu
    Sonra ekran görüntüsünde bazı menü metinlerinin de tuhaf olduğunu fark ettim; nedeni Chrome’un “Bu sayfayı çevir” seçeneğinin açık olmasıymış
    Uygulama içinde dili doğru şekilde nasıl değiştireceğini gösterince sorun ortadan kalktı

    • Chrome’un sayfayı bozduğu bir bug keşfettikten sonra, tek sayfalı web uygulamasının tüm sayfalarına ilgili ayarı ekledik
      Artık uygulamaya veya öğelere uygulanabilecek yeni yönerge bu gibi görünüyor. Dinamik değiştirmeyi desteklemek istemedikleri için CSS değil gibi; görünüşü de çirkin: https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
      Bazen büyük tek sayfalı uygulamaların meta tag’lerine bakarken, o tag’in neden gerekli olduğunu araştırma sürecinde yeni bir korku keşfediyorum
    • Bu gerçekten sinir bozucu
      Japonca web sitelerini okurken Google Translate’e sık sık güveniyorum ama React kullanan her web sitesi bozuluyor
      Çünkü React ve Google Translate birbirinden habersiz şekilde DOM düğümlerini güncellemeye çalışıyor
      Daha sonra bu sorunu yaşamayan web widget’ları tekrar yapabilir miyim diye Google Translate implementasyonuna ciddi ciddi bakmıştım
      [1] https://bugs.chromium.org/p/chromium/issues/detail?id=872770
    • İngilizceyi Amerikan İngilizcesine mi çevirdi, ne yaptı, merak ediyorum
    • Bu hikâye DaylyWTF gibi bir yere gönderilecek kadar komik

  • Fazlasıyla tanıdık bir sorun
    Daha önce Chrome’un erişilebilirlik araçlarının açılır menülerde böyle bir soruna yol açtığını görmüştüm; küçücük bir HTML ile bile yeniden üretilebiliyordu
    İki yıl önce benim takıldığım spesifik bug Chromium-Edge’deydi ama belirtiler ve neden çok benzerdi
    Grammarly neredeyse kesin olarak Chrome’un erişilebilirlik araçlarının bir kısmına dayanıyordur
    Bu tür araçlar Edge, Brave, Chrome gibi Chromium türevlerinde küçük farklılıklar gösteriyor

    • Bu hipoteze göre Grammarly Desktop GIF’i görüyor, bir şekilde tarayıcı erişilebilirlik fonksiyonlarını çağırıyor ve Chrome bunu işleyemeyip çöküyor anlamına mı geliyor, merak ediyorum

  • Bir dahaki sefere böyle bir şey olursa sadece başka bir tarayıcı kullandırmayı öneririm
    Özellikle Firefox’un Chrome’dan yer imleri, parolalar vb. içe aktarma özelliği çok daha iyi hâle geldi
    Evren artık geçiş yapma zamanının geldiğine dair bir sinyal göndermiş; bizim sinyali reddetmemiz mümkün değil
    Bu arada Firefox mühendisiyim ama bu tavsiyeyle hiçbir ilgisi yok

    • Mühendis açısından Firefox iyi bir çözüm, evet
      PM açısından bakınca, onboarding’i kolaylaştırmak için 4 ay harcadık; şimdi insanlara yeni tarayıcı kurmalarını mı söyleyelim, diye düşündürüyor
    • Bağlantı verilen yazıda zaten geçici çözüm olarak açıkça belirtilmiş
    • Chrome pazarın yarısından fazlasına sahip
      Tarayıcı tabanlı bir ürünün dünyada en çok kullanılan tarayıcıda düzgün çalışmaması iyi bir işaret değil

  • Güvenlik gerekçesiyle Chrome çökme raporlarını engellerken çalışanların Grammarly kurmasına izin veren kurumsal güvenlik politikalarına gerçekten bayılıyorum