Mac'te uygulama çökmeleri genellikle çok nadirdir. Ancak bu gerçekleştiğinde, bu sorunları takip etmek isteyebilirsiniz. Ve eğer bir geliştiriciyseniz uygulamanızın neden çöktüğünü anlamalısınız. MacOS'ta kilitlenme raporlarını kodlanmış dile göre nasıl okuyacağınız ve sıralayacağınız aşağıda açıklanmıştır.
Hızlı Linkler
Kilitlenme raporlarını aç
Mac'inizde bir uygulama çöktüğünde otomatik olarak bir kilitlenme raporu oluşturur. Bunun, kilitlenmeden sonra "[Uygulama] beklenmedik bir şekilde durduruldu" yazan bir uyarı iletişim kutusuyla birlikte göründüğünü göreceksiniz. Bu kilitlenme raporu, bu pencerede "Raporla..." düğmesine tıklanarak hemen okunabilir. Kilitlenme raporu Konsol uygulamasında da bulunabilir.
1. Spotlight'ta "Konsol" yazarak Konsol uygulamasını açın veya "Uygulama -> Yardımcı Programlar -> Console.app" seçeneğine gidin.
2. Soldaki menüde “Kullanıcı Raporları”na tıklayın ve ardından görüntülemek istediğiniz kilitlenme raporuna tıklayın. Bu dosyaların tümü “.crash” ile bitiyor ve başlıkta tarihi ve çöken uygulamayı içeriyor. Kilitlenme raporunun ayrıntıları sağdaki bölmede mevcuttur.
Mac OS kilitlenme raporlarını okuyun
Kaza raporunu yukarıdan aşağıya doğru inceleyelim.
Ne kırıldı?
Kilitlenme raporunun ilk bölümü size bir sürecin veya uygulamanın "bozuk" olup olmadığını söyler. Bir sorun giderici için en önemli kısım süreç adıdır.
İşlem: aText [11473] Yol: /Applications/aText.app/Contents/MacOS/aText Tanımlayıcı: com.trankynam.aText Sürüm: 2.19 (62) Kod Türü: X86-64 (Yerel) Üst İşlem: ??? [1] Sorumlu: aText [11473] Kullanıcı Kimliği: 501
Arıza ne zaman meydana geldi?
İkinci kısım bize arızanın ne zaman meydana geldiğini anlatır. Ayrıca sisteminiz hakkında biraz bilgi sağlar.
Tarih/Saat: 2018-03-15 00:58:10.552 -0400 İşletim Sistemi Sürümü: Mac OS 630000 saniye Sistem Bütünlüğü Koruması: etkin
Arızaya ne sebep oldu?
Bir sonraki kısım en aydınlatılmış kısımdır. Uygulamanın oluşturduğu “İstisna Türü” bize çökmeye neyin sebep olduğunu anlatır. Ayrıca hangi iş parçacığının çöktüğünü günlüğe kaydeder ve bildirir: bu durumda iş parçacığı 0'dır.
Çöken İş Parçacığı: 0 Dağıtım kuyruğu: com.apple.main-thread İstisna Türü: EXC_BAD_ACCESS (SIGSEGV) İstisna Kodları: KERN_INVALID_ADDRESS 0x000040dedeadbec0 adresinde İstisna Notu: EXC_CORPSE_NOTIFY Sonlandırma Sinyali: Bölümleme hatası: 11 Sonlandırma Nedeni: Ad alanı SİNYALİ, Kod 0xb Sonlandıran İşlem: istisna işleyici [0]
Apple listeleri Bazı yaygın istisna türleri Teknik belgelerinde:
Kötü Bellek Erişimi (EXC_BAD_ACCESS / SIGSEGV / SIGBUS) – Program belleğe yanlış erişmeye çalışıyor veya geçersiz bir adres kullanıyor. Bellek sorununu açıklayan kodla birlikte.
anormal çıkış (EXC_CRASH/SIGABRT) – anormal çıkış, genellikle yakalanmamış bir C++ istisnası ve bir iptal() çağrısının elindedir
İzleme Tuzağı (EXC_BREAKPOINT / SIGTRAP) – SIGABRT ile aynıdır, ancak bu sonlandırma, ekli hata ayıklayıcıya işlemi bir kesme noktasında kesme ve hatayı izleme fırsatı verir.
Yasadışı talimat (EXC_BAD_INSTRUCTION / SIGILL) – Anlaşılmayan veya işlenemeyen verilen işleme işleniyor.
Çık (SIGQUIT) – İşlem, yeterli ayrıcalıklara sahip başka bir işlem tarafından sonlandırıldı. Normalde izleme süreci hatalı uygulama işlemini sonlandırır.
SONLANDIR (SIGKILL) – Sistem isteği üzerine işlem sonlandırıldı. İstisnayı açıklamak için bir çıkış kodu eklenecektir.
Kilitlenme raporundan da görebileceğimiz gibi uygulama, karantinaya alınmamış belleğe erişmeye çalıştı. Bunun nedeni, uygulamadaki bir programlama hatası veya uygulamanın belleği yanlış eşlemesine neden olan olağandışı bir kullanıcı durumudur.
Arızaya ne sebep olur?
Daha sonra, kazaya neden olan olayların ters kronolojik bir listesini görüyoruz. Bunlar iş parçacığı 0'dan başlayarak iş parçacığına göre sıralanır.
Bu raporun dört sütunu var. Birincisi olay numarasını 0'dan başlayarak ters kronolojik sırayla bildirir. İkincisi ise işlem kimliğidir. Üçüncüsü ise sürecin bellekteki adresidir. Dördüncüsü programın görevinin adıdır.
Bu “gerileme” biraz kafa karıştırıcı olabilir. "Semboliktir", yani bazı bellek adreslerinin işlevlerin veya uygulama görevlerinin adlarıyla değiştirildiği anlamına gelir. Bazen bu tamamen yapılamaz ve okunamayan bellek adresleri raporun her yerine dağılmış halde kalır.
Bunu yukarıdaki kilitlenme raporunda görüyoruz: com.trankynam.aText sembolik değildir. Tam kodlamayla bile arka ucun okunması zor olabilir. Yazılım geliştiricileri bazen uygulama görevleri ve olayları hakkında yararlı notlar içerir. Diğer zamanlarda bunlar şifrelenmiş adresler veya dijital kodlardır. Eğer sembolizmi anlayabilirseniz, neler olduğunu da anlayabilirsiniz. Ancak mümkün olduğunca geri izlemeyi anlamak için uygulamayı kendiniz kodlamanız gerekecektir.
Sonuç: Bu yararlı mı?
Bir yazılım geliştiricisiyseniz kilitlenme raporlarını okumak çok önemlidir. Bu, uygulamanızın hangi bölümünün sorunlara neden olduğunu ve nedenini anlamanıza yardımcı olur. Kullanıcıysanız, bunlar yararlı değildir. Ancak sürekli çökmeler yaşıyorsanız kilitlenme raporları sorunu gidermenize veya sorunu düzeltmek için bir geliştiriciyle birlikte çalışmanıza yardımcı olabilir. Hata kodunun Google aracılığıyla yararlı bir şekilde çözülmesini sağlayabilir veya doğru bilgilerle teknik desteğe sağlayabilirsiniz. Eğer ciddi ayrıntılar istiyorsanız, bununla ilgili her şeyi şu adreste okuyabilirsiniz: Çökmelere İlişkin Apple Teknik Notu.
