Bun का नया क्रैश रिपोर्टर

Bun का नया Crash Reporter

• Bun v1.1.5 में Zig और C++ के लिए एक नया क्रैश रिपोर्ट फ़ॉर्मैट बनाया गया है
• क्रैश रिपोर्ट लगभग 150-बाइट के ऐसे URL में समाहित होती है जिसमें कोई भी व्यक्तिगत जानकारी नहीं होती

OS crash reporter का इस्तेमाल क्यों नहीं किया जाता?

• macOS जैसे कुछ OS में बिल्ट-इन crash reporter होता है, लेकिन आम तौर पर debug symbols को application के साथ ship करना पड़ता है
• Linux के लिए debug symbols लगभग 30MB, macOS पर लगभग 9MB होते हैं
• Windows में .pdb फ़ाइलें 250MB से भी बड़ी होती हैं
• Bun की सभी installation files में इन्हें जोड़ना बहुत भारी पड़ता है
• लेकिन debug symbols के बिना crash जानकारी बहुत सीमित हो जाती है, और ASLR की वजह से सभी function addresses बेकार हो जाते हैं

नया crash reporter

• Bun v1.1.5 में crash या panic होने पर एक संदेश प्रिंट होता है
• bun.report लिंक पर क्लिक करने से stack trace को URL में encode किए गए पहले से भरे हुए GitHub issue form पर redirect किया जाता है

Addresses को उपयोगी बनाना

• Function addresses, security reasons के कारण randomize किए गए offsets के साथ memory में load किए गए application code के pointers होते हैं
• ट्रिक यह है कि binary के base address से address को बस घटा दिया जाए
• हर platform के API अलग हैं, इसलिए असल में यह function इससे काफी ज्यादा जटिल है
• Resulting address में अब भी image का offset शामिल रहता है
• छोटा URL encode करने के लिए इस offset को हटा दिया जाता है, लेकिन remapping से पहले इसे फिर से जोड़ना पड़ता है

bun.report की URL संरचना

• URL को कैसे encode किया गया है, इसे देखें तो:
  • Platform : platform को दर्शाने वाला एक single character. w x86_64 Windows के लिए, M aarch64 macOS के लिए आदि
  • Subcommand : bun test, bun install, bun run जैसे subcommand को दर्शाने वाला एक single character
  • Commit SHA : मौजूदा Bun version का commit SHA. बाद में debug symbols लाने के लिए इसका उपयोग होता है
  • Feature Flags : crash होने से पहले Bun में इस्तेमाल हुए API और features के संकेत
  • Stack trace addresses : ऊपर गणना किए गए addresses
  • Crash type : crash के प्रकार को दर्शाने वाला एक single character
  • Crash message : crash का message, जिसका format type के अनुसार अलग होता है

VLQ मज़ेदार है

• URL को पर्याप्त छोटा रखने के लिए stack trace addresses को base64 variable-length quantity numbers का उपयोग करके encode किया जाता है
• इससे छोटे numbers कम characters में encode हो जाते हैं, जबकि बड़े numbers भी encode किए जा सकते हैं
• यही तकनीक JavaScript source maps में line numbers स्टोर करने के लिए इस्तेमाल होती है

"Feature" क्या है?

• URL एक 64-bit integer भी encode करता है, जिसमें हर bit Bun के किसी खास feature के इस्तेमाल से मेल खाती है
• ये flags उन API और systems के बारे में संकेत देते हैं जो crash का कारण बने हो सकते हैं
• Zig की compile-time metaprogramming इस bitfield को आसानी से बनाने देती है
• Feature tracking के लिए global variables का एक container पहले से मौजूद था
• std.meta का उपयोग करके feature list पर iterate किया जा सकता है और list बनाई जा सकती है
• फिर हर feature के लिए एक bit इस्तेमाल करने वाला dynamically derived packed struct बनाया जा सकता है

इसकी core dump से तुलना कैसे होती है?

• Core dump में बहुत ज्यादा जानकारी होती है, लेकिन उसका आकार बड़ा होता है, वह debug symbols के बिना उपयोगी नहीं होती, और उसमें संभावित रूप से बहुत सी संवेदनशील या गोपनीय जानकारी हो सकती है
• JavaScript/TypeScript source code, environment variables, या दूसरी महत्वपूर्ण जानकारी report में भेजे जाने की संभावना से बचना चाहा गया
• इसी वजह से सिर्फ Zig/C++ stack trace और कुछ अन्य विवरण भेजे जाते हैं
• सब कुछ default रूप से भेजने के बजाय, यह approach (शायद) केवल वही भेजती है जो समस्या की जांच के लिए ज़रूरी है

डेमो

• Crash reporter को टेस्ट करने के लिए एक छोटा web app bun.report homepage पर उपलब्ध है
• Crash report URL के अंत में /view जोड़ने पर आप वहाँ पहुँचते हैं

Bun सैन फ्रांसिस्को में hiring कर रहा है

• अगर आपको इस तरह के projects में रुचि है, तो कंपनी सैन फ्रांसिस्को में engineers hire कर रही है
• वे ऐसे systems engineers की तलाश में हैं जो JavaScript का भविष्य बनाने में मदद करें

GN+ की राय

• व्यक्तिगत जानकारी जैसी संवेदनशील बातें शामिल कर सकने वाली पूरी crash dump file भेजने के बजाय, केवल न्यूनतम आवश्यक जानकारी से बनी crash report भेजने का तरीका एक अच्छा approach लगता है.

• Core dump की तुलना में बहुत कम आकार में ज़रूरी जानकारी देना इसका फायदा है, लेकिन debugging के लिए आवश्यक जानकारी कम पड़ सकती है—यह इसकी कमी भी हो सकती है. ज़रूरत पड़ने पर उपयोगकर्ता से अतिरिक्त जानकारी माँगी जा सकती है, इसलिए इस कमी को कुछ हद तक कवर किया जा सकता है.

• VLQ का उपयोग करके stack trace addresses को encode करने का विचार प्रभावशाली है. छोटे आकार में बहुत-सी जानकारी पहुँचाने का यह एक efficient तरीका है. JavaScript source maps में इस्तेमाल होने वाली तकनीक का यह दिलचस्प उपयोग लगता है.

• कुल मिलाकर crash reporting system के design में काफी सोच-विचार और रचनात्मक विचार दिखाई देते हैं. वास्तविक crash reports के जरिए Bun की stability और usability बेहतर करने में यह काफी मददगार हो सकता है.

• अगर default report में उपलब्ध न होने वाली अतिरिक्त जानकारी की ज़रूरत पड़े, तो उपयोगकर्ता को crash report के हर field की जानकारी खुद समझकर देनी पड़ सकती है. advanced users न होने पर इसे समझना मुश्किल हो सकता है. इसे और user-friendly बनाने के तरीकों पर भी विचार किया जा सकता है.