Bun’ın yeni crash reporter’ı

Bun’ın yeni Crash Reporter’ı

• Bun v1.1.5, Zig ve C++ için yeni bir crash raporu formatı oluşturuyor
• Crash raporu, hiçbir kişisel bilgi içermeyen yaklaşık 150 baytlık bir URL’ye sığıyor

Neden işletim sistemi crash reporter’ını kullanmıyor?

• macOS gibi bazı işletim sistemlerinde yerleşik bir crash reporter var, ancak genelde debug sembollerini uygulamayla birlikte dağıtmanız gerekiyor
• Linux için debug sembolleri yaklaşık 30MB, macOS için yaklaşık 9MB
• Windows’ta .pdb dosyaları 250MB’ı aşıyor
• Bun’ın tüm kurulum dosyalarına eklemek için bu boyut fazla büyük
• Ancak debug sembolleri olmadan crash bilgisi çok sınırlı kalıyor ve ASLR nedeniyle tüm fonksiyon adresleri işe yaramaz hale geliyor

Yeni crash reporter

• Bun v1.1.5’te bir crash veya panic oluştuğunda bir mesaj yazdırılıyor
• bun.report bağlantısına tıklayınca stack trace’in URL’ye kodlandığı, önceden doldurulmuş bir GitHub issue formuna yönlendiriliyor

Adresleri kullanışlı hale getirmek

• Fonksiyon adresleri, güvenlik nedeniyle rastgeleleştirilmiş bir ofset içeren, uygulama kodunun yüklendiği bellekteki pointer’lardır
• İşin püf noktası, adresi binary’nin taban adresinden çıkarmaktır
• Her platformun farklı API’leri olduğundan, pratikte bu fonksiyon çok daha karmaşıktır
• Ortaya çıkan adresler hâlâ image içindeki ofseti içerir
• Daha kısa URL’ler kodlamak için bu ofset kaldırılır, ancak yeniden eşleme yapmadan önce tekrar eklenmesi gerekir

bun.report URL yapısı

• URL’nin nasıl kodlandığını incelersek:
  • Platform : Platformu gösteren tek bir karakter. w, x86_64 Windows’u; M ise aarch64 macOS’u ifade eder
  • Alt komut : bun test, bun install, bun run gibi alt komutları gösteren tek bir karakter
  • Commit SHA : Geçerli Bun sürümünün commit SHA’sı. Daha sonra debug sembollerini getirmek için kullanılır
  • Feature Flags : Bun çökmeden önce kullanılan API’ler ve özellikler için işaretler
  • Stack trace adresleri : Daha önce hesaplanan adresler
  • Crash türü : Crash türünü gösteren tek bir karakter
  • Crash mesajı : Crash’in mesajı; türe göre formatı değişir

VLQ eğlencelidir

• URL’yi yeterince kısa tutmak için stack trace adresleri, base64 değişken uzunluklu quantity sayıları kullanılarak kodlanır
• Bu sayede küçük sayılar daha az karakterle kodlanabilirken büyük sayılar da temsil edilebilir
• Bu, JavaScript source map’lerinde satır numaralarını depolamak için kullanılan tekniğin aynısıdır

“Feature” nedir?

• URL ayrıca, her biti Bun’ın belirli bir özelliğinin kullanılıp kullanılmadığına karşılık gelen 64 bitlik bir tamsayı da kodlar
• Bu flag’ler, crash’e yol açmış olabilecek API’ler ve sistemler hakkında ipucu verir
• Zig’in derleme zamanlı metaprogramlama özellikleri bu bit alanını kolayca oluşturmayı sağlar
• Özellik takibi için global değişkenlerden oluşan bir kapsayıcı zaten vardı
• std.meta kullanılarak özellik listesi üzerinde dönülebilir ve bir liste oluşturulabilir
• Sonrasında, özellik başına bir bit kullanacak şekilde dinamik olarak türetilmiş bir packed struct oluşturulabilir

Bu, core dump ile nasıl karşılaştırılır?

• Core dump çok daha fazla bilgi içerir, ancak boyutları büyüktür; işe yarar olması için debug sembolleri gerekir ve potansiyel olarak hassas ya da gizli çok sayıda bilgi içerebilir
• Raporun içine JavaScript/TypeScript kaynak kodu, ortam değişkenleri veya diğer önemli bilgilerin gönderilmesi olasılığından kaçınmak istediler
• Bu yüzden yalnızca Zig/C++ stack trace’i ve birkaç ek ayrıntı gönderiliyor
• Her şeyi varsayılan olarak göndermek yerine bu yaklaşım, (muhtemelen) sorunu teşhis etmek için gerekenleri gönderiyor

Demo

• Crash reporter’ı test edebileceğiniz küçük bir web uygulaması bun.report ana sayfasında mevcut
• Crash raporu URL’sinin sonuna /view eklerseniz buraya ulaşırsınız

Bun, San Francisco’da işe alım yapıyor

• Bu tür projeler ilginizi çekiyorsa, San Francisco’da mühendis alımı yapıyorlar
• JavaScript’in geleceğini inşa etmeye yardımcı olacak sistem mühendisleri arıyorlar

GN+ görüşü

• Kişisel bilgiler gibi hassas veriler içerebilen crash dump dosyasının tamamını göndermek yerine, yalnızca gerekli en az bilgiden oluşan bir crash raporu göndermek iyi bir yaklaşım gibi görünüyor.

• Core dump’a kıyasla çok daha küçük boyutla gerekli bilgileri sağlayabilmesi bir avantaj; ancak debugging için gereken bilgilerin yetersiz kalabilmesi de bir dezavantaj gibi görünüyor. Gerektiğinde kullanıcıdan ek bilgi istenebilmesi, bu dezavantajı bir ölçüde telafi edebilir.

• VLQ kullanarak stack trace adreslerini kodlama fikri etkileyici. Küçük boyutla çok fazla bilgi aktarmayı sağlayan verimli bir yöntem. JavaScript source map’lerinde kullanılan bir teknik olması da ilginç bir kullanım örneği.

• Genel olarak crash reporting sistemi tasarımına ciddi düşünce ve yaratıcı fikirler yansımış gibi görünüyor. Gerçek crash raporları üzerinden Bun’ın kararlılığına ve kullanılabilirliğine önemli katkı sağlayabilir.

• Varsayılan raporda sunulmayan ek bilgilere ihtiyaç duyulduğunda, kullanıcının crash raporundaki her alanın ne anlama geldiğini kendisinin anlayıp sağlaması gerekebilir; bu da ileri düzey olmayan kullanıcılar için zor olabilir. Bunu daha kullanıcı dostu hale getirecek yolları değerlendirmek faydalı olabilir.