En zor böcek avınız neydi ve nasıl bulup öldürdünüz?


31

Bu bir "Bilgi Paylaşımı" sorusudur. Başarılarından ve / veya başarısızlıklarından öğrenmek istiyorum.

Yardımcı olabilecek bilgiler ...

Arka fon:

  • Bağlam: Dil, Uygulama, Çevre vb.
  • Hata nasıl tespit edildi?
  • Hatayı kim ya da ne tanımladı?
  • Böceği ne kadar karmaşık hale getiriyordu?

Avlanma.

  • Planın neydi?
  • Hangi zorluklarla karşılaştınız?
  • Suçlu kod nihayet bulundu?

Öldürmek.

  • Düzeltme ne kadar karmaşıktı?
  • Düzeltmenin kapsamını nasıl belirlediniz?
  • Düzeltmede ne kadar kod yer aldı?

Ölümden.

  • Teknik olarak kök neden neydi? tampon taşması vb.
  • 30.000 fit'in kök nedeni neydi?
  • Süreç sonunda ne kadar sürdü?
  • Düzeltmeden olumsuz etkilenen özellikler var mıydı?
  • Hangi yöntemleri, araçları, motivasyonları özellikle yararlı buldunuz? ... korkunç yararsız?
  • Eğer hepsini tekrar yapabilseydin? ............

Bu örnekler geneldir, her durumda geçerli değildir ve muhtemelen yararsızdır. Lütfen gerektiği gibi sezon.

Yanıtlar:


71

Aslında, uygulamamızın 3. parti bir resim görüntüleyici alt bileşenindeydi.

Uygulamamıza katılan kullanıcıların 2-3 kişisinin sık sık resim görüntüleme bileşeninin bir istisna atmasına ve korkunç bir şekilde ölmesine neden olacağını gördük. Ancak, iş gününün çoğunda aynı görev için uygulamayı kullanmamıza rağmen, sorunu hiç görmemiş düzinelerce kullanıcı daha vardı. Ayrıca özellikle onu diğerlerinden daha sık alan bir kullanıcı vardı.

Her zamanki adımları denedik:

(1) Bilgisayarı / yapılandırmayı ekarte etme sorunu olmayan bilgisayarları başka bir kullanıcıyla değiştirdiler. - Sorun onları takip etti.

(2) Uygulamaya giriş yapmış ve sorunu hiç görmemiş bir kullanıcı olarak çalışmışlardı. - STILL sorunu onları takip etti.

(3) Kullanıcı hangi görüntüyü görüntülediklerini bildirmiş ve hızlı bir şekilde art arda görüntüyü binlerce kez tekrarlamak için bir test demeti kurmuştu. Sorun koşumda kendini göstermedi.

(4) Bir geliştirici, kullanıcılarla birlikte oturup bütün gün onları izlemiş. Hataları gördüler, ancak sıra dışı olarak kendilerine sebep olacak bir şey yaptıklarını fark etmediler.

"Hatalı Kullanıcılar" ın diğer kullanıcıların sahip olmadıklarını ortak ne bulduğunu anlamaya çalışmakla haftalarca bunun için mücadele ettik. Nasıl bir fikrim yok ama 4. adımdaki geliştirici, bir gün Encyclopedia Brown'a layık olan bir iş için arabada eureka anı yaşadı.

Tüm "Hata Kullanıcıları" nın elden bırakıldığını fark etti ve bu gerçeği doğruladı. Yalnızca solak kullanıcılar hataları aldı, hiçbir zaman Righties. Ancak, el bırakılmak nasıl bir böceğe neden olabilir?

Onu oturttuk ve solcuları özel olarak farklı yaptıkları her şeye dikkat ederek yeniden izlettirdik ve bu şekilde bulduk.

Böceğin yalnızca fareyi resim görüntüleyicideki en sağdaki piksel sütununa getirdiğinizde (satıcı, mouseover olayı için 1 kez hesaplanan bir hesaplamaya sahip olduğu için taşma hatası) ortaya çıktı.

Görünüşe göre, bir sonraki görüntünün yüklenmesini beklerken, kullanıcılar doğal olarak ellerini (ve dolayısıyla fareyi) klavyeye doğru hareket ettirdiler.

En sık hatayla karşılaşan kullanıcı, bir sonraki sayfanın yüklenmesini beklerken faresini zorla sabırla hareket ettiren ADD türlerinden biriydi, bu nedenle fareyi çok daha hızlı bir şekilde sağa doğru hareket ettiriyordu. tam doğru zamanlama bu yüzden load olayı gerçekleştiğinde o yaptı. Satıcıdan bir çözüm bulana kadar, sadece fareyi tıkladıktan sonra (bir sonraki belge) bırakıp yüklenene kadar dokunmamasını söyledik.

Bundan böyle dev takımın efsanesinde "Sollak Böcek" olarak biliniyordu.


14
Bu şimdiye kadar duyduğum en kötü şey.
Nathan Taylor

9
Yine de, onu çözen adamdan bir kahraman yarattı.
JohnFx

2
Vay canına, şimdi bu bir hata çilesi!
Mitchel Sellers

3
Harika bul! Güzel hikaye.
Toon Krijthe

11
Sanki solcular gibi ikinci sınıf vatandaşlar gibi yeterince muamele görmemişiz. Şimdi ayrıca, yazılım hatalarındaki adil payımızdan daha çok üzülmeliyiz ... gee, teşekkürler! : p
Dan Mould

11

Bu çok uzun zaman önceydi (1980'lerin sonunda).

Çalıştığım şirket, çeşitli Unix iş istasyonlarında (HP, Sun, Silcon Graphics vb.) Çalışan bir CAD paketi (FORTRAN'da) yazdı. Verileri depolamak için kendi dosya formatımızı kullandık ve paket başlatıldığında disk alanı azdı, bu yüzden varlık başlıklarında birden fazla bayrak depolamak için kullanılan çok fazla bit kaydırma vardı.

Varlığın türü (çizgi, yay, metin vb.) Depolandığında 4096 (sanırım) ile çarpılmıştır. Ek olarak, silinen bir öğeyi belirtmek için bu değer ihmal edildi. Yani türünü almak için yaptığımız kod vardı:

type = record[1] MOD 4096

Biri hariç her makinede ± 1 (bir çizgi için), ± 2 (bir ark için) vb. Verdi ve silinip silinmediğini görmek için işareti kontrol edebiliriz.

Bir makinede (HP sanırım), silinen öğelerin kullanımının berbat olduğu garip bir sorun yaşadık.

Bu IDE'lerin ve görsel hata ayıklayıcıların önündeki günlerdeydi, bu yüzden sorunu izlemeye ve izlemeye çalışmak için izleme ifadeleri ve günlük kaydı eklemeliydim.

Sonunda her üretici uygulanan ederken çünkü olduğunu keşfetti MODböylece -4096 MOD 4096sonuçlandı -1HP matematiksel olarak doğru böylece onu hayata -4096 MOD 4096sonuçlandı -4097.

Değerin işaretini kaydeden kod tabanının tamamından geçmek zorunda kaldım MODve sonucu gerçekleştirmeden önce pozitif hale getirdim ve sonucu işaret değeriyle çarptım.

Bu birkaç gün sürdü.


3
Muhtemelen yıllar boyunca daha zor böcek avı olmuştur, ama bu 20 yıldan beri aklımda kalmış!
ChrisF

7

Vay, burada okumak güzel!

En sertim, Turbo Pascal'ın büyük olduğu yıllardı, ancak o zamanın ilk C ++ IDE'lerinden biri olabilirdi. Tek geliştirici olarak (ve bu başlangıçta üçüncü adam olarak) basitleştirilmiş bir satış elemanı dostu CAD programı gibi bir şey yazmıştım. O zamanlar harikaydı, ancak kötü bir rastgele kaza geliştirdi. Çoğaltmak imkansızdı, ancak böcek avına başladığım kadar sık ​​oldu.

En iyi stratejim, hata ayıklayıcısında bir adım atmaktı. Hata sadece kullanıcı bir çizimden yeterince içeri girdiğinde ve belirli bir modda veya yakınlaştırma modunda olması gerektiğinde gerçekleşmiştir, bu nedenle, çizime girmek için normalde bir dakika boyunca çalışan, sıkıcı ayar ve temizleme kesme noktaları vardı. büyük bir kod yığınını adım adım izleyin. Özellikle yardımcı olanlar, ayarlı sayıyı birkaç kez atlayacak ve sonra kesilecek olan kesme noktalarıydı. Bütün bu egzersiz birkaç kez tekrarlanmalıydı.

Sonunda onu bir alt rutinin çağrıldığı, 2 verildiği bir yere daralttım ancak içinden bir anlamsız rakam gördü. Bunu daha önce yakalayabilirdim, ancak verilenlere sahip olduğunu farz ederek bu alt rutine girmedim. En basit şeylerin tamam olduğunu kabul ederek kör etti!

Yığına 16 bit int dolduruyordu, ancak alt yordam 32 bit bekliyordu. Ya da böyle bir şey. Derleyici tüm değeri otomatik olarak 32 bit'e doldurmadı ya da yeterli tip kontrolü yapmadı. Bir çizginin sadece bir kısmını düzeltmek, gerekli herhangi bir düşünceyi düzeltmek için önemsizdi. Fakat oraya varmak üç gün sürdü.

Bu yüzden, bir süre sonra bir yere bir kez dokunan ve 2000 $ 'a mal olan pahalı danışman hakkındaki sözler hakkında kişisel tecrübem var. Yöneticiler bir arıza talep ediyor ve musluk için 1 dolar, nereye dokunacağını bilmek için 1999 dolar. Benim durumum hariç, zaman para değildi.

Alınan dersler: 1) "en iyi" nin bilgisayar biliminin nasıl kontrol edeceğini bildiği kadar çok sorunun kontrol edilmesini de içermek olarak tanımlandığı en iyi derleyicileri kullanmak ve 2) basit olan şeyleri sorgulamak veya en azından uygun şekilde işlevlerini doğrulamak.

O zamandan beri tüm zor böcekler gerçekten zordu, çünkü basit şeyleri gerektiğinden daha iyice kontrol ettiğimi biliyorum.

Ders 2 aynı zamanda önemsiz bir düzeltme ile bugüne kadar çözdüğüm en zor elektronik hata için de geçerlidir, ancak birkaç akıllı EE aylarca bekletildi. Ama bu elektronik bir forum değil, bundan daha fazla diyemeyeceğim.


Lütfen elektronik hatasını başka bir yere ve buraya bir link gönderin!
tgkprog

6

Cehennemden gelen ağ veri yarış durumu

Başka bir geliştirici tarafından yazılmış, gerçekten eski (Encore 32/77) bir iş istasyonunda benzer bir uygulamayla çalışmak için bir ağ istemcisi / sunucusu (Windows XP / C #) yazıyordum.

Uygulamanın temelde yaptığı şey, sistemi çalıştıran ana bilgisayarı kontrol etmek için fantezi PC tabanlı çoklu monitör dokunmatik ekran kullanıcı arayüzümüzle belirli verileri paylaşmak / üzerinde değişiklik yapmaktı.

Bunu 3 katmanlı bir yapıyla yaptı. İletişim süreci, ana bilgisayara veri okudu / yazdı, gerekli tüm format dönüşümlerini (endianness, kayan nokta formatı, vb.) Yaptı ve değerleri bir veritabanına yazdı / okudu. Veritabanı, iletişim ve dokunmatik ekran kullanıcı arayüzleri arasında bir veri aracı olarak görev yaptı. Dokunmatik ekran UI'nin uygulaması, PC'ye kaç monitör eklendiğine bağlı olarak dokunmatik ekran arayüzleri oluşturdu (bunu otomatik olarak algıladı).

Ev sahibi ile bilgisayar arasında bir değer paketi verilen zaman çerçevesinde, tel gezintisi başına maksimum ~ 110ms gecikme süresi olan bir seferde tel boyunca maksimum 128 değer gönderebilir (UDP, arasında bir x-over ethernet bağlantısı ile kullanıldı) bilgisayarlar). Bu nedenle, eklenen dokunmatik ekranların değişken sayısına bağlı olarak izin verilen değişken sayısı sıkı kontrol altındaydı. Ayrıca, ana bilgisayar (gerçek zamanlı hesaplama için kullanılan paylaşılan bellek veriyolu ile oldukça karmaşık bir çok işlemcili mimariye sahip olmasına rağmen), cep telefonumun işlem gücünün yaklaşık 1 / 100'üne sahipti, bu yüzden mümkün olduğu kadar az işlem yapması gerekiyordu ve sunucusuydu. / istemcinin bunu sağlamak için montajda yazılması gerekiyordu (ev sahibi programımızdan etkilenmeyen tam zamanlı bir simülasyon kullanıyordu).

Sorun buydu. Dokunmatik ekranda değiştirildiğinde bazı değerler sadece yeni girilen değeri almayacak, ancak bu değer ile önceki değer arasında rasgele bir döngü oluşturacaktı. Bu ve sadece belirli bir sayfa kombinasyonuyla belirli bir sayfadaki birkaç belirli değerde belirti ortaya çıktı. İlk müşteri kabul süreci boyunca yayınlamaya başlayana kadar sorunu neredeyse tamamen kaçırdık


Bu sorunu çözmek için salınan değerlerden birini seçtim:

  • Dokunmatik ekran uygulamasını kontrol ettim, salınım yapıyordu
  • Veri tabanını kontrol ettim, salınımlı
  • İletişim uygulamasını kontrol ettim, salınımlı

Daha sonra wireshark'tan ayrıldım ve paket yakalamalarını el ile çözmeye başladım. Sonuç:

  • Salınımlı değil, paketler doğru görünmüyordu, çok fazla veri vardı.

Haberleşme kodunun her detayında yüzlerce kez hata / hata bulamadım.

Sonunda, diğer uçta e-postaları ateşlemeye başladım, detaylı bir şekilde eksik olduğum bir şeyin olup olmadığını görmek için nasıl çalıştığını sordum. Sonra onu buldum.

Görünüşe göre, veri gönderdiğinde, iletimden önce veri dizisini temizlemediği için, aslında esasında, eskinin üzerine yazılan yeni değerlerle birlikte kullanılan son tamponun üzerine yazıyordu, ancak eski değerlerin üzerine yazılmıyordu.

Bu nedenle, bir değer veri dizisinin 80. konumundaysa ve istenen değerlerin listesi 80'den küçükse, ancak aynı değer yeni listede mevcutsa, o zaman her iki değer de belirli bir arabellek için veri arabelleğinde mevcut olacaktır. verilen zaman.

Veritabanından okunan değer, UI'nin değeri istediği zaman dilimine bağlıdır.


Düzeltme acı vericiydi. Veri arabellekten gelen öğelerin sayısını okuyun (Aslında paket protokolünün bir parçası olarak bulunurdu) ve arabellek bu sayıdaki öğelerin ötesinde okunmadı.


Dersler öğrenildi:

  • Verilmiş olan modern bilgi işlem gücünü almayın. Bilgisayarların ethernet'i desteklemediği ve bir diziyi temizlerken pahalı sayılabilecek bir zaman vardı. Gerçekten ne kadar geldiğimizi görmek istiyorsanız, neredeyse hiç dinamik bellek ayırma şekli olmayan bir sistem hayal edin. IE, yürütme sürecinin tüm programların belleğini tüm programlar için önceden tahsis etmesi gerekiyordu ve hiçbir program bu sınırın ötesine geçemezdi. IE, tüm sistemi yeniden derlemeden bir programa daha fazla bellek ayırmak büyük bir çökmeye neden olabilir. İnsanların çöp toplama günleri hakkında bir gün aynı ışıkta konuşup konuşmayacaklarını merak ediyorum.

  • Özel protokollerle ağ kurarken (ya da genel olarak ikili veri sunumunu kullanırken), borudan gönderilen her değerin her fonksiyonunu anlayana kadar spesifikasyonu okuduğunuzdan emin olun. Demek istediğim, gözlerin acıtıncaya kadar oku. İnsanlar verileri, tek tek bitleri veya baytları manipüle ederek ele alırlar; işleri yapmanın çok akıllıca ve verimli yolları vardır. En küçük ayrıntıyı kaçırmamak sistemi bozabilir.

Düzeltmek için gereken genel süre 2-3 gündü ve çoğu zaman bununla uğraşmak zorunda kaldığımda başka şeyler üzerinde çalışmakla geçti.

SideNote: Söz konusu ana bilgisayar varsayılan olarak ethernet'i desteklemiyordu. Sürmek için kullanılan kart özel olarak yapıldı ve güçlendirildi ve protokol yığını neredeyse yoktu. Çalıştığım geliştirici, bir cehennem programcısıydı, bu proje için sistemde UDP'nin soyulmuş bir versiyonunu ve basit bir sahte ethernet yığınını (işlemci tam bir ethernet yığınını idare edecek kadar güçlü değildi) uygulamıştı. ama bir haftadan az bir sürede yaptı. Ayrıca, işletim sistemini ilk başta tasarlayan ve programlayan özgün proje ekibi liderlerinden biri olmuştu. Diyelim ki, ne kadar sarıldığına veya ne kadar yeni olduğumdan bağımsız olarak bilgisayarlar / programlama / mimarlık hakkında paylaşmak zorunda olduğu her şeyi, her kelimeyi dinlerdim.


5

Arkaplan

  • Bir görev kritik WCF uygulamasında bir web sitesi sürüş ve arka uç trasactional işleme sağlayan ..
  • Büyük hacimli uygulama (saniyede yüzlerce arama)
  • Birden çok sunucu birden çok örnek
  • yüzlerce başarılı ünite testi ve sayısız KG olayı

Böcek

  • Üretime taşındığında, sunucu rastgele bir süre boyunca iyi çalışır ve ardından hızlıca bozulmaya başlar ve kutu CPU'yu% 100'e alır.

Nasıl buldum

İlk başta bunun normal bir performans sorunu olduğundan emindim, bu yüzden ayrıntılı bir günlük kaydı oluşturuyorum. Veritabanında konuşulan her çağrıdaki performans kontrol edildi. 1 hafta

Sonra bir iş parçacığı çekişme sorunum olduğuna emindim. Kilitlenme durumumu hata ayıklamada durum yaratmaya çalışmak için araçlar oluşturma girişimleri denemek için kontrol ettim. Artan yönetim hayal kırıklığı ile, projeyi sıfırdan başlayarak sunucuyu bir iş parçacığına sınırlamak için işleri önerme konusunda arkadaşlarımın yanına döndüm. 1,5 hafta

Sonra Tess Ferrandez'e baktım. bloguna bir kullanıcı döküm dosyası oluşturdum ve sunucuyu bir sonraki çöplükten sonra windebug ile değiştirdim. Bütün iş parçacıklarım dictionary.add işlevinde sıkıştı.

Kısa süre önce, sadece x thread hataları yazmak için hangi günlüğü takip eden kısa bir küçük sözlük senkronize edilmedi.


3

Bazı durumlarda, cihazın fişi tekrar takılana ve iki kez yumuşak sıfırlanana kadar fiziksel olarak çıkarılmışsa doğru şekilde çalışamayacağı bir donanım cihazıyla konuşan bir uygulamamız vardı.

Sorun, başlangıçta çalışan bir uygulamanın, henüz eklenmemiş bir dosya sisteminden okumaya çalışırken (örneğin, bir kullanıcı bir NFS biriminden okumak üzere yapılandırılmışsa) zaman zaman farklılaşıyor olduğu ortaya çıktı. Başlangıçta, uygulama, cihazı başlatmak için sürücüye bazı ioctls'ler gönderir, ardından yapılandırma ayarlarını okur ve cihazı doğru duruma getirmek için daha fazla iosct gönderir.

Sürücüdeki bir hata, başlatma çağrısı yapıldığında cihaza geçersiz bir değerin yazılmasına neden oluyordu, ancak çağrılar cihazı belirli bir duruma getirmek için çağrılar yapıldıktan sonra, değerin üzerine geçerli veriler yazılmıştı.

Cihazın bir bataryası vardı ve anakarttan güç kaybedip alamadığını algılayacak ve güç kaybının olduğunu belirten geçici belleğe bayrak yazacak, daha sonra çalıştırıldığında belirli bir duruma girecek ve belirli bir duruma girecekti. bayrağın kaldırılması için talimatın gönderilmesi gerekiyordu.

Sorun, cihazın başlatılması için ioctls'ler gönderildikten sonra güç kesildiyse (ve geçersiz değeri cihaza yazdıysa) ancak geçerli veriler gönderilmeden önce idi. Cihaz tekrar açıldığında, bayrağın ayarlandığını görecek ve eksik başlatma nedeniyle sürücüden gönderilen geçersiz verileri okumaya çalışacaktır. Bu, cihazı kapalı bayrağının kaldırıldığı geçersiz bir duruma getirecek, ancak sürücü tarafından yeniden başlatılana kadar cihaz daha fazla talimat alamayacaktır. İkinci sıfırlama, cihazın üzerinde saklanan geçersiz verileri okumaya çalışmadığı ve doğru instructionsktl'leri gönderen uygulamanın farklı olmadığı varsayılarak, doğru duruma getirilmesine izin veren doğru yapılandırma talimatları alacağı anlamına gelir. ).

Sonunda soruna neden olan koşulların tam olarak belirlenmesi iki hafta sürdü.


2

Bir üniversite projesi için, dosyaları paylaşan bir Dağıtılmış P2P Düğümleri sistemi yazıyorduk, bu birbirlerini saptamak için çok noktaya yayın, çoklu düğüm halkaları ve bir ad sunucusu, böylece bir düğüm müşteriye atandı.

C ++ ile yazılmış, biz güzel IO, Socket ve Thread programlamasına izin verdiği için POCO'yu kullandık .


Bizi rahatsız eden ve çok fazla zaman kaybetmemize neden olan, gerçekten mantıklı olan iki hata vardı:

Rastgele, bir bilgisayar uzak IP yerine yerel ana bilgisayar IP'sini paylaşıyordu.

Bu, istemcilerin aynı PC'deki düğüme veya kendileriyle bağlantı kurması için düğümlere bağlanmasına neden oldu.

Bunu nasıl tespit ettik? Ad sunucusundaki çıktıyı iyileştirdiğimizde, daha sonra, verilecek IP’yi belirlemek için komut dosyamızın yanlış başlatıldığı bilgisayarları yeniden başlattığımızda keşfettik. Rastgele, ilk önce eth0 aygıtı yerine lo aygıtı listeleniyordu ... Gerçekten aptalca. Bu yüzden artık tüm üniversite bilgisayarları arasında paylaşıldığı için eth0'dan talep etmesini zorladık.


Ve şimdi daha sinir bozucu olanı:

Rastgele, paket akışı rastgele duraklar.
Bir sonraki müşteri bağlandığında devam ederdi ...

Bu gerçekten rastlantısal olarak gerçekleşti ve birden fazla bilgisayar olduğu için, bu sorunu ayıklamak daha can sıkıcı hale geldi, üniversite bilgisayarları Wireshark'ı çalıştırmamıza izin vermiyor, bu yüzden sorunun gönderici taraf mı yoksa alıcı mı olduğunu tahmin etmekten vazgeçtik yan.

Koddaki birçok çıktıyla, komutların gönderilmesinin iyi gittiği varsayımına ulaştık,
bu bizi asıl sorunun nerede olduğunu merak etti ... Görünüşe göre POCO'nun anketlerinin yanlış olduğu ve bunun yerine kullanılabilir karakterleri kontrol etmemiz gerektiği ortaya çıktı. gelen sokette.

Bunun daha az paket içeren bir prototipte daha basit testler olarak çalıştığını varsaydık. Bu soruna neden olmadı, bu yüzden anket anketinin çalıştığını varsaymamıza neden oldu. :-(


Dersler öğrenildi:

  • Ağ cihazlarının sırası gibi aptal varsayımlarda bulunmayın.

  • Altyapılar her zaman işlerini yapmaz (uygulama veya belgeler) doğru yapmaz.

  • Kodda yeterli çıktı sağlayın, izin verilmezse, genişletilmiş ayrıntıları bir dosyaya kaydettiğinizden emin olun.

  • Kod test edilmediğinde (çünkü çok zor) işe yaramaz.


1
Wireshark (veya benzeri bir araç) olmadan ağ iletişimi sorunlarını çözmek, kendi içinde / içinde kahramancadır.
Evan Plaice

2

Hala en zor böcek avımdayım. Bazen oradakilerden, bazen de böceklerden değil. Bu yüzden ertesi gün sabah 6: 10'da buradayım.

Arka fon:

  • Bağlam: Dil, Uygulama, Çevre vb.
    • PHP OS Ticaret
  • Hata nasıl tespit edildi?
    • Rastgele sıra, iş parçasının rastgele başarısız olduğu ve sorunları yönlendirdiği yoludur.
  • Hatayı kim ya da ne tanımladı?
    • Müşteri ve yönlendirme sorunu açıktı
  • Böceği ne kadar karmaşık hale getiriyordu?
    • Yeniden üretemedim ama müşteri bunu yapabildi.

Avlanma.

  • Planın neydi?
    • Hata ayıklama kodu ekleyin, sipariş doldurun, verileri analiz edin, tekrarlayın
  • Hangi zorluklarla karşılaştınız?
    • Tekrarlanabilir problemlerin olmaması ve korkunç kod
  • Suçlu kod nihayet bulundu?
    • bir sürü rahatsız edici kod bulundu .. tam olarak ihtiyacım olanı bulamadım.

Öldürmek.

  • Düzeltme ne kadar karmaşıktı?
    • çok
  • Düzeltmenin kapsamını nasıl belirlediniz?
    • kapsam yoktu ... her yerdeydi
  • Düzeltmede ne kadar kod yer aldı?
    • Hepsini? Dokunulmamış bir dosya olduğunu sanmıyorum

Ölümden.

  • Teknik olarak kök neden neydi? tampon taşması vb.
    • kötü kodlama uygulaması
  • 30.000 fit'in kök nedeni neydi?
    • Söylememeyi tercih ederim ...
  • Süreç sonunda ne kadar sürdü?
    • sonsuza dek ve bir gün
  • Düzeltmeden olumsuz etkilenen özellikler var mıydı?
    • özellik? ya da bir hata mı?
  • Hangi yöntemleri, araçları, motivasyonları özellikle yararlı buldunuz? ... korkunç yararsız?
  • Eğer hepsini tekrar yapabilseydin mi?
    • ctrl + a Del

Sebep "kötü kodlama uygulaması" ise, ekibinizin kodlama uygulamalarını gözden geçirmek ve belki de meslektaş değerlendirmesini yapmak için uygun bir zaman ise patronunuzla görüşmek isteyebilirsiniz.

2

Son semseterdaki kafa karıştırıcı eşzamanlılık sorunlarını düzeltmek zorunda kaldım, ama yine de benim için en çok göze çarpan hata, bir ev ödevi için PDP-11 meclisinde yazdığım metin tabanlı bir oyundu. Conway'in Yaşam Oyununa dayanıyordu ve garip bir nedenden dolayı, kılavuzun yanındaki bilgilerin büyük bir kısmı, orada olmaması gereken bilgilerle sürekli üzerine yazılıyordu. Mantık da oldukça basitti, bu yüzden kafa karıştırıcıydı. Tüm mantığın doğru olduğunu yeniden keşfetmek için birkaç kez üzerinden geçtikten sonra aniden sorunun ne olduğunu fark ettim. Bu şey:.

PDP-11'de, bir sayının yanındaki bu küçük nokta, 8 yerine taban 10'u yapar. Büyüklüğü, aynı sayılarla fakat temel olarak tanımlanmış ızgarayla sınırlı olması beklenen bir halkayı bağlayan sayının yanındaydı. 8.

Bu hala benim için göze çarpıyor çünkü 4 piksel büyüklüğünde küçük bir ilaveye neden olan hasar miktarı. Peki sonuç nedir? PDP-11 montajında ​​kodlama yapmayın.


2

Ana Çerçeve Programı Sebepsiz Çalışmayı Durdurdu

Bunu başka bir soruya gönderdim.İşte Mesaj bak

Bu, ana kareye derleyicinin daha yeni bir sürümünü yükledikleri için oldu.

06/11/13 Güncellemesi: (Orijinal cevap OP tarafından silinmiştir)

Bu ana çerçeve uygulamasını devraldım. Bir gün, berrak mavi olanın dışında çalışmayı bıraktı. İşte bu ... sadece durdu.

Benim işim mümkün olduğunca çabuk çalışmasını sağlamaktı. Kaynak kodu iki yıl boyunca değiştirilmedi, ancak aniden durdu. Kodu derlemeye çalıştım ve XX. Satırda kırdı. XX no'lu çizgiye baktım ve XX no'lu çizginin kırılmasının ne olacağını söyleyemedim. Bu uygulama için ayrıntılı özellikleri istedim ve hiçbiri yoktu. XX hattı suçlu değildi.

Kodu yazdırdım ve en baştan aşağı incelemeye başladım. Neler olduğuna dair bir akış şeması oluşturmaya başladım. Kod o kadar karmaşıktı ki, neredeyse hiç anlamamıştım. Akış şeması yapmaya çalışmaktan vazgeçtim. Özellikle uygulamanın ne yaptığı hakkında hiçbir bilgim olmadığından, bu değişimin sürecin geri kalanını nasıl etkileyeceğini bilmeden değişiklikler yapmaktan korkuyordum.

Bu yüzden, kaynak kodunun başından başlamaya ve kodu daha okunaklı hale getirmek için boşluk ve el freni eklemeye karar verdim. Bazı durumlarda, AND'leri ve OR'leri birleştiren koşullar olup olmadığını ve hangi verinin ANDed olduğu ve hangi verinin ORed'le verildiği arasında açıkça ayırt edilemeyeceğini fark ettim. Ben de onları daha okunaklı hale getirmek için AND ve OR koşullarının etrafına parantez koymaya başladım.

Yavaş yavaş temizlerken aşağıya doğru ilerlediğim zaman periyodik olarak işimi kurtaracağım. Bir noktada kodu derlemeye çalıştım ve garip bir şey oldu. Hata atlandı orijinal kod satırını geçti ve şimdi daha da aşağıdaydı. Ben de AND ve OR koşullarını parens ile ayırmaya devam ettim. Temizlemeyi bitirdiğimde işe yaradı. Şekil git.

Daha sonra ameliyathaneyi ziyaret etmeye karar verdim ve ana çerçeveye yakın zamanda yeni bir bileşen takıp takmadıklarını sordum. Evet dediler, yakın zamanda derleyiciyi yükselttik. Hmmmm.

Eski derleyicinin ifadesini soldan sağa ne olursa olsun değerlendirdiği ortaya çıktı. Derleyicinin yeni versiyonu ayrıca soldan sağa doğru ifadeleri de değerlendirdi ancak belirsiz kodlar, AND'lerin ve OR'lerin belirsiz bir kombinasyonu çözülemedi.

Bundan öğrendiğim ders ... HER ZAMAN, HER ZAMAN, HER ZAMAN, birbirleriyle bağlantılı olarak kullanıldığında HER ZAMAN ayrılan VE koşullarını ve VEYA koşullarını kullanırlar.


bağlantı noktalarınızın kaldırıldığı gönderi - yanıtı güncelleyebilir misiniz?
gnat

1
@gnat - archive.org'da bulmuş :)
Michael Riley - AKA Gunny

1

Arka fon:

  • Bağlam: Müşterilerin kendilerini kontrol etmelerini sağlayan Web Sunucusu (C ++)
  • Hata: Sayfayı talep ederken, sayfanın sunulması çok uzun sürdüğü (sadece birkaç saniye izin verildiği için), sayfanın tamamı için yanıt vermeyecek, tüm çiftlik ve süreçler öldürülecekti (ve yeniden başlatılacak).
  • Bazı kullanıcılar şikayet etti, ancak çoğunlukla farkedilmeden aşırı derecede sporadik (insanlar bir sayfa sunulmadığında "Yenile" ye basmaya meyillidirler). Çekirdek dökümlerini olsa da farkettik;)
  • Aslında yerel ortamlarımızda hiç çoğalmayı başaramadık, test sistemlerinde hata birkaç kez ortaya çıktı, ancak Performans Testleri sırasında hiç görünmedi.

Avlanma.

  • Plan: Eh, hafıza dökümü ve kayıtlarımız olduğundan, onları analiz etmek istedik. Tüm çiftliği etkilediğinden ve geçmişte bazı veritabanı sorunlarımız olduğundan, veritabanından şüphelendikten (birkaç sunucu için tek DB)
  • Zorluklar: Dolu bir sunucu dökümü çok büyük ve bu yüzden oldukça sık temizleniyorlar (alan tükenmemek için), bu yüzden gerçekleştiğinde birini kapmak için hızlı olmak zorunda kaldık ... Israr ettik. Dökümler, çeşitli yığınlar (hiçbir zaman DB olayı olmadı, bunun için çok fazla) gösterdi, sayfanın kendisini hazırlarken başarısız oldu (önceki hesaplamalarda değil) ve günlüklerin gösterdiğini doğruladı, sayfanın hazırlanmasının bazen çok zaman alacağını doğruladı Yine de önceden hesaplanmış veriye sahip basit bir şablon motor (geleneksel MVC).
  • Başlarken: Biraz daha fazla örnek ve biraz düşündükten sonra, HDD’den veri okuma zamanının geldiğini fark ettik (sayfa şablonu). Tüm çiftlikle ilgili olduğu için ilk önce planlı işler aradık (crontab, partiler) ama zamanlamalar bir olaydan diğerine asla eşleşmedi ... Sonunda bunun her zaman yeni bir versiyonun aktivasyonundan birkaç gün önce gerçekleştiğini düşündüm. Yazılımın bir AhAh vardı ! an ... yazılımın dağıtımından kaynaklandı! Birkaç yüz megabayt (sıkıştırılmış) sunmak, disk performansına bir miktar zarar verebilir: / Tabii ki dağıtım otomatik ve arşiv aynı anda tüm sunuculara gönderiliyor (çok noktaya yayın).

Öldürmek.

  • Karmaşıklığı Onar: derlenmiş şablonlara geçme
  • Etkilenen Kod: yok, derleme işleminde basit bir değişiklik

Ölümden.

  • Kök neden: operasyonel konu veya ileri planlama eksikliği :)
  • Zaman Ölçümü: İzlemesi aylar aldı, düzeltilmesi ve test edilmesi birkaç gün sürdü, KG ve Performans testi ve dağıtımı için birkaç hafta vardı - orada acele etmeyin, çünkü düzeltmeyi dağıtmanın hatayı tetikleyeceğini biliyorduk ... başka ... tür gerçekten sapık!
  • Olumsuz yan etkiler: şablonları çalışma zamanında artık kodun içinde kodlandığı için değiştirilememesi, özelliği çok fazla kullanmadık, çünkü genellikle şablonlar arasında geçiş yapmak daha fazla veriye sahip olduğunuz anlamına geliyor. "küçük" düzen değişiklikleri için çoğunlukla yeterli.
  • Yöntemler, araçlar: gdb + izleme! Diski şüphelendikten sonra bize zaman ayırdı ve ardından izleme grafiğindeki ... ... aktivite artışının nedenini belirledik.
  • Bir dahaki sefere: tüm IO'ları ters davranın!

1

En zoru asla öldürülmedi çünkü fabrika işletmesiyle birlikte tam üretim ortamından başka bir şekilde çoğaltılamaz.

Öldürdüğüm en çılgınca:

Çizimler saçma basıyor!

Koda baktım ve hiçbir şey göremiyorum. Bir işi yazıcı kuyruğundan çekip inceliyorum, iyi görünüyor. (Bu, gömülü HPGl / 2 özellikli PCL5 dozundaydı - aslında, çizimleri çizmek için çok iyi ve sınırlı bellekte raster bir görüntü oluşturmanın baş ağrıları yok.) Bunu anlaması gereken başka bir yazıcıya yönlendirdim .

Kodu geri al, sorun hala orada.

Sonunda elle basit bir dosya oluşturup yazıcıya gönderiyorum - anlamsız. Görünüşe göre yazıcı kendimden başka bir şey değildi. Bakım şirketi, başka bir şeyi tamir ederken en son sürüme ulaştırdı ve o son sürümde hata vardı. Onları kritik bir işlevsellik çıkardıklarını ve daha eski bir sürüme geri götürmek zorunda olduklarını anlamalarını sağlamak, böceğin kendisini bulmaktan daha zordu.

Daha da can sıkıcı biriydi, fakat sadece kutumda olduğundan ilk etapta olmazdım:

Borland Pascal, bazı desteklenmeyen API'lerle başa çıkmak için DPMI kodu. Çalıştır, bazen işe yaradı, genellikle geçersiz bir işaretçi ile uğraşmaya çalışırken patladı. Ancak, bir işaretçinin üzerinde durmayı beklediğiniz gibi, asla yanlış bir sonuç vermedi.

Hata ayıklama - kodu tek adım attığımda her zaman doğru çalışır, aksi takdirde önceki gibi kararsızdı. Muayene her zaman doğru değerleri göstermiştir.

Suçlu: İki vardı.

1) Borland'ın kütüphane kodunda büyük bir hata vardı: Gerçek mod işaretçiler, işaretçi değişkenlerinde korumalı modda saklanıyordu. Sorun, gerçek moddaki işaretçilerin çoğunun korumalı modda geçersiz segment adreslerine sahip olması ve işaretçiyi kopyalamaya çalıştığınızda onu bir kayıt defteri çiftine yükledikten sonra kaydetmesidir.

2) Hata ayıklayıcı, tek adımlı modda böyle bir geçersiz yük hakkında hiçbir şey söylemez. Dahili olarak ne yaptığını bilmiyorum ama kullanıcıya sunulanlar tamamen doğru görünüyordu. Aslında talimatı yerine getirmediğinden, onun yerine taklit edildiğinden şüpheleniyorum.


1

Bu sadece bir şekilde benim için bir kabusa dönüşen basit bir hata.

Arka plan: Kendi İşletim Sistemimi yapmak için çalışıyordum. Hata ayıklama çok zordur (izleme ifadeleri sahip olabileceğiniz tek şeydir ve bazen bu bile değil)

Hata: Kullanıcı modunda iki iplik anahtarı yapmak yerine, genel koruma hatası olur.

Böcek avı: Muhtemelen bir ya da iki haftamı bu sorunu çözmeye çalışarak geçirdim. Her yerde izleme ifadeleri ekleme. Üretilen derleme kodunun incelenmesi (GCC'den). Elimden gelen her değeri yazdırıyorum.

Sorun: Böcek avının başlarında bir yerlerde hlt, crt0'a bir talimat verdim. Crt0, işletim sisteminde kullanım için kullanıcı programını önyükleme işlemidir. Buhlt komut kullanıcı modundan çalıştırıldığında GPF'ye neden olur. Oraya yerleştirdim ve temelde unuttum. (başlangıçta sorun arabellek taşması ya da bellek ayırma hatasıydı)

Düzeltme: hltTalimatı kaldırın :) Çıkardıktan sonra her şey düzgün çalıştı.

Ne öğrendim: Bir sorunu ayıklamaya çalışırken, denediğiniz düzeltmeleri izlemeyin. Düzenli olarak en son kararlı kaynak kontrol sürümüne göre değişiklik yapın ve yakın zamanda başka hiçbir şey çalışmadığında ne değiştiğini görün

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.