DOOM'da, gerçek donanımda 2,5 yıllık kullanımın ardından çökme yaşandığı doğrulandı

• DOOM motorundaki bir değişken taşması nedeniyle oyunun çökmesi durumunun yaşandığı doğrulandı
• Gerçek kullanım ortamında 2,5 yıl boyunca DOOM çalıştırma deneyi gerçekleştirildi
• Değişken değeri sürekli artarken taşma noktasına ulaşıldı ve beklenen anda oyunun kapanması yaşandı
• Deney, PDA ve DIY UPS kullanılarak uzun süreli otomatik çalışma ortamında yürütüldü
• Bu test, teorik bir problemin gerçek dünyada da gerçekten ortaya çıktığını kanıtlıyor

---

Deneyin arka planı ve motivasyonu

• Yaklaşık 2,5 yıl önce, DOOM motorunun yapısı ve çalışma biçimiyle ilgili bir yazı okunurken, demo çalıştırma takibinde kullanılan bir değişkenin her demo başlangıcında sürekli arttığı fark edildi
• Bu değişken bir önceki değerle karşılaştırılıyor, ancak değer tekrar tekrar büyüdüğü için sonunda taşma riski barındırıyordu
• Normal kullanım ortamında bu taşma durumuna ulaşmak zor olsa da, gerçekte ne kadar sürdüğünü doğrudan görmek için deney yapmaya karar verildi

Deney yöntemi ve süreci

• Basit bir hesaplamayla, taşmanın gerçekleşmesi için yaklaşık 2,5 yıllık çalışma süresi gerektiği tahmin edildi
• Bunu gerçekten doğrulamak için bir PDA cihaza DOOM kuruldu ve güç, 18650 pil kullanan bir DIY UPS ile sağlandı
• Cihaz, sürekli 5V güç sağlamak için router'ın USB portuna bağlandı
• Sistem, otomatik şarj ortamında sürekli çalışacak şekilde ayarlandıktan sonra zamanın büyük bölümünde kendi hâline bırakıldı

Çökme anı ve sonuçlar

• Deneyin başlamasından yaklaşık 2,5 yıl sonra, cihaz ekranında bir açılır bildirim göründüğü fark edildi
• DOOM, beklendiği gibi taşmanın neden olduğu sert bir çökme durumuna geçti
• Deney sonucu, değişken taşmasına bağlı oyun kapanmasının gerçek donanım ve gerçek yazılım ortamında da ortaya çıkabildiğini kanıtladı

Sonuç ve çıkarımlar

• Programlamada uzun süre boyunca birikerek artan değişkenlere dikkat edilmesi gerektiği vurgulanıyor
• Yalnızca teorik bir olasılık gibi görülen taşma probleminin gerçekte de patlak verebileceği deneysel olarak doğrulandı
• Legacy kodlar veya uzun süre çalışan yazılımlardaki gizli kusurlara karşı farkındalık oluşturuyor

[GN⁺]

Hacker News görüşleri

• Yaklaşık 1 yıl önce Crash Bandicoot'un zamanlayıcı sistemine bakarken Crash 3'te int32 türündeki bir değerin sürekli arttığını fark etmiştim; yapı gereği yalnızca ölünce sıfırlanıyor. 2,26 yıl açık kalırsa taşma oluyor ve o anda süre "eksi"ye dönerek oyunu çeşitli komik şekillerde bozuyor. Bununla ilgili bir video hazırlamıştım: YouTube bağlantısı

  • Final Fantasy 9'da belirli bir silahı almak için 12 saat içinde (Avrupa sürümünde 10 saat) oyunun sonlarına yakın bir bölgeye ulaşmak gerekiyor, ama bir bug yüzünden zamanlayıcı taşana kadar oyunu 2 yıl açık bıraksanız bile alınabiliyor. Yani rahat rahat bekleyip yine hedefe ulaşabiliyorsunuz: ayrıntılı açıklama bağlantısı

  • Videonda bir kez bile "crash" kelime oyununa gitmemiş olman şaşırtıcı. Donma durumuna da crash diyebilirdin; biraz kaçırılmış fırsat gibi.

  • Zamanlayıcı takibi için varsayılan olarak signed integer kullanmanın ne kadar yaygın olduğunu merak ediyorum. Unsigned olsaydı taşmaya kadar süre iki katına çıkardı; neden böyle bir seçim yapıldı acaba?

  • Sanırım birçok oyun böyleydi. SotN'de de global bir zamanlayıcı var. 32 bit sistemlerde birkaç ay, bilemedin birkaç yıl oynanacak bir oyun için yılların geçişini özellikle test etmeye gerek duymamışlardır. O dönemde kimse yazdığı yazılımın hackleneceğini, analiz edileceğini, tersine mühendisliğe uğrayacağını hayal etmiyordu herhalde. Biz de günlük program yazarken bunları çok hesaba katmıyoruz.

  • Gerçek bir Time Twister kilidi açılmış.

• Oynanamaz denebilecek bir durum gibi görünüyor; umarım biri bunu mutlaka düzeltir. Doom gerçekten harika bir oyun ve her birkaç yılda bir dönüp tekrar oynuyorum. 2016 reboot'u da eğlenceliydi ama ondan sonraki oyunlar bana pek hitap etmedi.

  • Klasik Doom tarzı oynanışı sevenler için bir topluluk var: r/boomershooters

  • Ben de aynı fikirdeyim. Son oyunlardaki metroidvania tasarımı ve home hub yapısı eski hissi vermiyor. Koş, düşmanları indir, gizlileri bul ve bir sonraki bölüme geç tarzı sade akış bana daha iyi geliyor.

  • Ben de öyle düşünüyorum; özellikle brutality modunu çok seviyorum.

  • İlginç bir bilgi: Doom artık Quake, StarCraft, WarCraft, Overwatch, Infocom ve Sierra'nın tüm adventure oyunları ve Halo ile birlikte Microsoft'un mülkiyetinde. Microsoft 1996'dan beri PC oyunlarının fikri mülkiyetinin büyük kısmını toplamaya çalışıyordu; neredeyse başarmış sayılır.

  • 2016 yapımı, oynadığım en iyi single-player FPS'ti. Ona yaklaşan tek şey Titan Fall 2 oldu.

• Donanım seviyesinde taşmayı trap'leyen bir özellik olup olmadığını merak ediyorum. Doom motorunun nasıl çalıştığına dair bir yazıda, demo takip değişkeninin bir sonraki demo başlasa bile artmaya devam ettiğini okumuştum. Bu değişken ikinci bir değişkenle, yani önceki değeri tutan değişkenle karşılaştırılıyor. Asıl oyunun neden crash verdiğini merak ediyorum.

  • C dilinde signed overflow tanımsız davranıştır, yani sonuç öngörülemez. Ama burada platformdan ya da derleyiciden bağımsız olarak aynı şekilde oluyorsa mesele bu değil gibi. TFA'ya göre bu değişken önceki değeriyle karşılaştırılıyor ve new < old durumunun ortaya çıkacağı hesaba katılmadan kod yazılmış. Bu da stack bozulması gibi bug'lara kolayca yol açabilir. C'de mesela return değeri olmayan bir fonksiyonun değer döndürmesi gereken bir noktaya ulaşması da gayet rahat şekilde tanımsız davranış üretir.

• Bug'ın nedenini önceden biliyor olmasına şükretmek lazım. 2,5 yıl geçtikten sonra "lanet olsun, debug logunu açmayı unutmuşum" diye fark etmek de mümkündü.

• DOOM, Windows CE'den önce crash vermiş.

  • Ben en çok, bir uygulamanın PDA üzerinde 2,5 yıl boyunca aralıksız çalışmış olmasına şaşırdım. İnternet bağlantısı kesik halde, güncel donanımda bunun mümkün olup olmayacağından ciddi şekilde şüpheliyim.

  • Gerçekten etkileyici bir rekor.

• Site muhtemelen aşırı trafik yüzünden çökmüş, bu yüzden bir archive.org bağlantısı bırakıyorum: archive.org arşiv bağlantısı. Ne yazık ki sitenin biçimlendirmesinin tamamı korunmamış ama metin duruyor.

• 2038 ilginç bir yıl olacak gibi.

  • Birçok kişi 2036'daki NTP sorununu gözden kaçırıyor; asıl parti o zaman başlayacak.

  • 2038, y2k döneminden çok daha yakın hissettiriyor.

  • 64 bit int'e geçmek ya da time_t'yi long long türüne çevirmek için 13 yıl kaldı. Birçok gömülü cihaz veya desteği bitmiş kapalı sistem özel dikkat gerektirecek. Eskiden kullandığım SunServer 600MP'nin OpenFirmware'inde de aynı sorun vardı. Neyse ki artık benim için dert değil.

  • O sorunu çözmek benim emeklilik planım.

• Benim tanıdığım hiçbir test ekibi bu seviyede test yapmaz. Çalıştığım sistemde bile daha dün, 30 saniyelik timeout sonrası hata işleme akışını görmek için 5'ten fazla kez beklemem gerekti; inanılmaz sinir bozucuydu.

• Bir zamanlar Windows NT 4'te de benzer bir bug vardı; sistem uptime'ını ölçen yüksek hassasiyetli bir sayaçla ilgiliydi. Service Pack 3'ten (veya 2'den) önce, sistemleri zamanlayıcıyla her ayın 1'inde yeniden başlatıyorduk. Yoksa yaklaşık 42 günlük uptime sonrası crash oluyordu. Demek ki Microsoft bile bir sunucu işletim sisteminin bu kadar uzun süre aralıksız çalışacağını düşünmemiş.

  • Acaba sözünü ettiğin şey bu bağlantıda bahsedilen sorun mu, yoksa NT 4'te ayrı bir bug daha mı vardı, merak ettim.

• id Software ekibine bir kez daha şapka çıkarıyorum. Bugün alışıldık yöntemlerle geliştirilmiş olsaydı, muhtemelen bellek parçalanması ya da bellek sızıntısı yüzünden 2 yılı görmeden çökerdi.