Debugging'e Giriş


Bilgisayar kullanırken kimi zaman kullandığımız uygulamalar beklenmedik davranışlar gösterirler. Bu davranışları iki gruba ayırabiliriz :

#1 Uygulama bir hata ile karşılaşır. Bu durumda ya kapanır ya da uyarı verir ve çalışmaya devam eder.

#2 Uygulama cevap veremez hale gelir.

Uygulamadan kastedilen tüm komut satırı uygulamaları, servisler ve GUI uygulamalarıdır. Uygulamanın .net tabanlı olup olmaması veya hangi programlama dilinde geliştirildiğinin bir önemi yok.

Beklenmeyen davranışın sebebini bulmak için kullanabileceğimiz güçlü bir araç mevcut : Debugger (hata ayıklayıcı). Debugger’ın yaptığı çalışan uygulamanın içine bakmamızı sağlamak. İsterseniz debugger’ı röntgen cihazı gibi de düşünebilirsiniz. Debugger, sorunlu uygulamaya bağlanabilir ve sizin bu uygulamayı incelemenizi sağlar. Tabii, akla gelen soru “Production/live (üretim/canlı) ortamlarında kimin bunu yapma şansı olabilir?” dir. Genellikle de yanıt “kimsenin” olacaktır. İşte tam bu noktada debugger’ın çok sık kullanacağımız bir özelliğinden bahsedebiliriz : dump dosyası  üretmek.

Dump dosyası, uygulamanın kullandığı bellek alanlarını, işlemci içeriğini ve işletim sisteminde tutulan bir takım bilgileri barındırır. Dump dosyası, debugger ile açılabilir. Dolayısıyla dump’ın alındığı anda uygulamanın durumunu daha sonra incelemek mümkün.

Debugger, nasıl başlatıldığına bağlı olarak aşağıdaki durumlarda dump dosyası üretebilir :

#1 Eğer debugger exception durumlarında dump dosyası üretmeye ayarlandıysa debugger uygulamaya bağlandığı andan itibaren onu takip eder ve bir exception olduğunda bir dump dosyası üretir. Debugger uygulama kapanana kadar çalışır ve ona bağlı kalır. Buna “Crash Mode” dump alma denir. “Crash Mode”dan kasıt mutlaka uygulamanın bir exception sonucu kapanması değildir. Her exception üretildiğinde dump alınmasıdır. Maalesef, “crash” sözcüğü bu karışıklığa yol açıyor.

#2 Diğer bir çalıştırma yöntemi ise debugger’in uygulamaya bağlanması ve o anki bilgileri dump dosyasına kaydetmesi, akabinde bağlantıyı kesip, kapanmasıdır. Uygulama çalışmaya devam eder. Debugger’ın bu tip çalıştırılmasına “Hang Mode” denir. Maalesef burada da “hang” sözcüğü farklı bir algıya yol açıyor. Debugger, uygulamanın ne zaman “hang” olduğunu ( cevap vermediğini ) takip etmez, fark edemez, sadece çalıştırıldığı o andaki uygulamanın durumunu kaydeder.

Sanıyorum, ilk yöntem “exception” ikincisi de “snapshot” mode olarak anılsaydı daha doğru olurdu.

Üretilen bu dosyalarla ilgili hiç unutulmaması gereken bir nokta var : Dump dosyası uygulamanın “o ana ait” durumunu gösterir, ne bir cycle önce ne de bir cycle sonra 🙂 Yani süreğen bir bilgi barındırmaz. Bu varsayımdan yola çıkarak hangi tip sorunlu durumda debugger’ı hangi halde başlatıp (crash/hang) kaç tane dump dosyasına ihtiyacımız olduğunu belirleyeceğiz.

 

Beklenilmeyen durumları tekrar gözden geçirelim :

Hata alınan durumlar

#1 Uygulama bir süre düzgün şekilde çalışıyor ancak herhangi bir anda “Beklenmeyen hata oluştu” gibi bir mesaj çıkıyor ve “tamam”a bastığınızda uygulama kapanıyor. Ya da bu uyarı dahi çıkmıyor ve uygulama kapanıyor.

Nasıl dump dosyası toplanır ?

Yapılması gereken uygulama çalışmaya başladıktan sonra debugger’ı “crash” modda çalıştırmak ve uygulama beklenmedik şekilde kapanana kadar beklemek. Amacımız hangi exception’ndan ötürü uygulamanın kapandığını anlamak. Daha sonra dump dosyası içinde exception'a yol açan call stack'i inceleyeceğiz.

 

#2 Uygulama bir süre düzgün çalışıyor. Ancak, belli bir işlevi çalıştırmak istediğinizde size hata mesajı döndürüyor. Mesajı kapattığınızda uygulama kapanmıyor ve geri kalan işlevler beklendiği gibi çalışmaya devam ediyor.

Nasıl dump dosyası toplanır ?

Hata mesajının gösterildiği anda debugger’i “hang” modda çalıştırmak. Amacımız MessageBox’ı gösteren call stack’i bulmak olacaktır. Buradaki ümidimiz mesaja yol açan fonksiyonların callstack'te hala mevcut olmaları.

 

#3 Uygulama çalıştıktan bir süre sonra yetersiz kaynaklarla ilgili mesajlar verir veya sistem/uygulama günlüklerine kayıt atmaya başlar. Kimi zaman uygulama kapanmaz ancak kesinlikle beklendiği gibi de davranmaz.

Nasıl dump dosyası alınır?

Bu kez soruya soruyla yanıt vereceğiz. Yapmamız gereken ilk şey dump almak mıdır ? Hayır! Öncelikle hangi kaynağın kullanılıp geri verilmediğini anlamalıyız. Örneğin, artan, uygulamanın sanal bellek alanı mıdır, yoksa işletim sistemi nesneleri ( dosya, thread, vs ) midir? Bunların yanıtı önce task manager’dan bu tip değerleri kontrol etmek, daha sonra uygulamanın çalışmaya başladığı andan itibaren sorun çıkarmaya başladığı zamana kadar performans sayaçları ile log toplayıp bir artış trendi gözlemlemeye çalışmaktır. Eğer bunları yapmaya fırsatımız olmadıysa o zaman bir hang dump almak işe yarayabilir. Elbette, bu dump dosyası büyük ihtimalle sadece neyin fazla kullanıldığını gösterecektir. Buna neden olan sebebi göstermeyecektir. Teorik olarak bir dump’tan sebebi öğrenme ihtimali de var ancak bunun için gerçekten şanslı olmalısınız ve uygulamanın kaynak kodunu yakından tanımalısınız.

 

Uygulamanın yanıt veremez hale gelmesi

Bu tip durumlarda yanıtlanması gereken iki soru var :

#1 Uygulamanın işlemci kullanımı ne düzeyde?

#2 Yanıt vermeme durumu ne kadar sürüyor?

 

Eğer işlemci kullanımı yüksek ( örneğin uygulama en az bir işlemcinin tamamını kullanıyorsa > %90 ) ve bu durum bir kez başladı mı uygulama kapanana kadar devam ediyorsa o zaman birer dakika arayla 3 kez “hang” mode dump almak gerekir. Bu durumlar genellikle uygulamanın sonsuz bir döngüye girmesinden kaynaklanır. Dump dosyalarında aynı thread’lere ait callstack’lerdeki ortak payda aranacaktır.

Eğer uygulamanın, işlemci kullanımı yüksek ve bu durum belirli bir süre devam ediyorsa ve sonra işlemci kullanımı normal oranlarına geri dönüyorsa mümkün olduğunca çok dump dosyası toplamak isabetli olacaktır. Eşit aralıklarla 4 tane dump almak iyi bir başlangıçtır. Ancak, bu durumlarda ( anlık yükseliş ) sadece dump dosyalarının içeriği yeterli olmayacaktır. Performans monitor yardımıyla sistemde diğer yükselen değerleri de gözlemlemek gerekir. Örneğin, disk I/O'su da artıyor mu? Sisteme gelen istek sayısında bir artış var mı? Çünkü; genellikle bu durum birim zaman içindeki istek sayısının artmasından kaynaklanır.

Eğer uygulamanın, işlemci kullanımı düşük ( neredeyse 0 ) ve bu durum uygulama kapanana kadar devam ediyorsa ve uygulama hiçbir isteğeye yanıt vermiyorsa o zaman bir kez “hang” dump almak yeterlidir. Bu tip durumlar, genellikle sonsuz bir bekleyişten kaynaklanır. Dump dosyasında thread’lerin callstack’leri incelenerek neyin beklendiğini ve neden yanıt alınamadığı araştırılır.

Eğer uygulamanın işlemci kullanımı düşük ve bu durum bir süre devam edip sonrasında çözülüyorsa o zaman durağan süre boyunca eşit aralıklarla 3-4 kez “hang” mode’da dump almak uygun olacaktır. Bu tip durumlar, genelikle uygulamanın başka bir uygulamadan yanıt beklemesinden kaynaklanır.

 

Son söz olarak, tek bir defa dump dosyası üretmek her zaman sorunun kaynağını aydınlatmada yardımcı olmayabilir. Aynı işlem ve hatta farklı modlarda tekrar dump almak gerekebilir.

Hoşçakalın

-faik

Comments (0)

Skip to main content