Korumalı hafızadan önce segmentasyon hatalarında nasıl hata ayıkladılar?

Şimdi, C'deki işaretçilerle bir programlama hatası yaptığımda, hoş bir segmentasyon hatası alıyorum, programım çöküyor ve hata ayıklayıcı bana nerede yanlış gittiğini bile söyleyebilir.

Hafıza korumasının mevcut olmadığı zamanlarda bunu nasıl yaptılar? Bir DOS programcısının hata yaptığında tüm işletim sistemini çökerttiğini ve çöktüğünü görebiliyorum. Sanallaştırma mevcut değildi, bu yüzden yapabileceği tek şey yeniden başlatmak ve yeniden denemekti. Gerçekten böyle mi gitti?

Bir DOS programcısının hata yaptığında tüm işletim sistemini çökerttiğini ve çöktüğünü görebiliyorum.

Evet, olan buydu. Bellek eşlemleri olan çoğu sistemde, konum 0 geçersiz olarak işaretlendi, böylece boş göstergeler kolayca algılanabildi, çünkü bu en yaygın durumdu. Ama başka davalar da vardı ve tahribat yarattılar.

Bir moruk gibi görünme riski altında, hata ayıklamaya şu anki odaklanmanın geçmiş yolu olmadığını belirtmeliyim. Hataların yanlış programlardan kaldırılmasından ziyade doğru programların yazılması için daha fazla çaba harcanmıştı. Bazıları bunun amacı bizim amacımızdı, ama çoğu araçların işleri zorlaştırmasıydı. Programlarınızı IDE'de değil, etkileşimli bir hata ayıklayıcıdan yararlanmadan kağıda veya delikli kartlara yazmayı deneyin. Size doğruluk için bir tat verir.

Benim günümde, bellek korumamız ve tüm bu şık işlerimiz yoktu! Programda nerede olduğumuzu belirlemek için printf kullandık ve beğendik !

Her şeye rağmen, bu genellikle daha dikkatli olduğumuz anlamına geliyordu. Malloc çağrıldığında, programda başka bir yerde ücretsiz olması gerekiyordu ve böyle bir kontrol titizdi, çünkü bir sorun olması durumunda, açıkça belirttiğiniz gibi, segmentasyon hataları yardımcı hatalar değildir.

Bu tür hatalarda yapabileceğiniz en iyi şey, bu tür segmentasyon hatalarının ne zaman meydana geldiğini (printf kullanarak) anlamaya çalışmak ve koda bakarak, o noktada belleğe erişimin neden geçerli olmadığını belirlemek ve oradan geriye doğru çalışmaktır.

Özünde, bugün de aynı şey olur, ancak hataların ne zaman meydana geldiğini belirlemek için hata ayıklayıcıları kullanırız, ancak bunun neden olduğunu anlamak zorundasınız ve hatanın oluştuğu satırı bulmak her zaman basit değildir. Hatalar zincir reaksiyonu gibi hatalara neden olur ve o günlerde bir C programcısı olsaydınız, zaman kodunuzun% 20'sini ve zamanın geri kalanını saçınızı hataların giderilmesi için harcadınız.

iyi ..

segfault, bir şeyin yanlış olduğunu gerçekten güzel bir göstergedir, ancak yine de kök nedeni bulmanız gerekir. Eğer soruyu sorarsanız, sorunun cevabını bugün nasıl bulduğunuzdan çok farklı değildir. Tabii ki diller ve araçlarla çalışmak daha kolay hale geldi, ancak genel taktik aynı:

• günlüğe kaydetme, sorunun bulunduğu alanı bulmanıza yardımcı olur. İkili arama printf bunun bir şeklidir.
• hata ayıklama, adım adım, kırılma noktaları ve saatler
• daha iyi bir anlayış elde etmek için yeniden düzenleme
• koda sert bakmak
• bellek / çekirdek boşluğuna bak
• farklı verilerle beslemek
• diğer insanlara göstermek
• işaretçisi olmayan bir dile (ve yeni bir sorun kümesine) geçin ...

Daha soyut bir düzeyde üç yaklaşım vardır: 1. kod ile çalışmak 2. çalışırken programa bakmak 3. aptalca bir şey yaptıktan sonra sonuçlara bakmak

btw işaretçi hatasının segfault oluşturması gerekmez.

Bir Amiga programcısı olarak hemen hemen hepsini kullandım. Ve evet ortak uygulama nerede yeniden başlar.

Fortran toplu işlerini yürüten IBM 360'ta, altı çekirdekli dökümleri alıyorduk. Böyle bir dökümü, bir inç kalınlığında fan-kat yeşil-beyaz yazıcı kağıdı kadar olabilir. Kayıtların ne olduğunu söylerdi ve oradan programın ne yaptığını geri izleyebilir ve çözebiliriz. Her altyordamı bulabilir ve dönüş adresini nerede sakladığını bulabiliriz, böylece içeriği görebiliriz. Programın bir montajcı listesine sahip olmak yardımcı olacaktır.

Bir zamanlar ünlü bir Windows 3.1 Sunum yazılımı üzerinde hata düzeltme üzerinde çalışıyordum.

Bir hata meydana geldiğinde, Ölümün Mavi Ekranına neden oldu.

Hata sadece belirli bir döngü 1000 defadan fazla yürütüldüğünde meydana geldi. Bir kırılma noktasının 1000 kez geçmesine izin vermek için hata ayıklayıcının gelişmiş özelliklerini kullandım ve sonra programa dikkatlice adım attım. Her zaman çok ileri gittim veya Windows Mavi Ekranlı hata içeren bir işlev çağrısı atladı.

Son olarak, birkaç gün çalıştıktan sonra, belleği yetersiz olan bir işleve daralttım ve bir hata mesajı görüntülemek yerine, hata mesajını arabelleğe ekledim. Sonraki her yinelemede, önemli bir şeyin üzerine yazılana ve Windows çöpe atılana kadar daha fazla bellek çöpe attı.

Hata ayıklama becerileri ve azim çözüm oldu.