Crash Reporter ใหม่ของ Bun

Crash Reporter ใหม่ของ Bun

• ใน Bun v1.1.5 ได้สร้างรูปแบบรายงานแครชใหม่สำหรับ Zig และ C++
• รายงานแครชจะถูกใส่ไว้ใน URL ขนาดราว 150 ไบต์ที่ไม่มีข้อมูลส่วนตัวเลย

ทำไมไม่ใช้ตัวรายงานแครชของระบบปฏิบัติการ?

• ระบบปฏิบัติการบางตัวอย่าง macOS มีตัวรายงานแครชในตัว แต่โดยทั่วไปต้องแจกจ่าย debug symbols ไปพร้อมกับแอปพลิเคชันด้วย
• debug symbols สำหรับ Linux มีขนาดประมาณ 30MB และของ macOS ประมาณ 9MB
• บน Windows ไฟล์ .pdb มีขนาดมากกว่า 250MB
• ขนาดใหญ่เกินกว่าจะเพิ่มเข้าไปในไฟล์ติดตั้งทั้งหมดของ Bun
• แต่ถ้าไม่มี debug symbols ข้อมูลแครชจะมีอย่างจำกัดมาก และเพราะ ASLR ทำให้ที่อยู่ฟังก์ชันทั้งหมดแทบไม่มีประโยชน์

Crash Reporter ใหม่

• ใน Bun v1.1.5 เมื่อเกิดแครชหรือ panic จะมีการแสดงข้อความ
• เมื่อคลิกลิงก์ bun.report จะถูกเปลี่ยนเส้นทางไปยังฟอร์ม GitHub Issue ที่กรอกไว้ล่วงหน้า โดยมี stack trace ถูกเข้ารหัสอยู่ใน URL

ทำให้ address ใช้งานได้จริง

• function address คือ pointer ในหน่วยความจำที่โหลดโค้ดของแอปพลิเคชัน พร้อม offset แบบสุ่มด้วยเหตุผลด้านความปลอดภัย
• เคล็ดลับคือเพียงแค่ลบ address ออกจาก base address ของไบนารี
• แต่ละแพลตฟอร์มมี API ต่างกัน ดังนั้นในทางปฏิบัติฟังก์ชันนี้จึงซับซ้อนกว่านั้นมาก
• address ที่ได้ยังคงมี offset ภายใน image อยู่
• เพื่อให้เข้ารหัส URL ให้สั้นลง offset นี้จะถูกลบออก แต่ต้องใส่กลับเข้าไปก่อนทำ remapping

โครงสร้าง URL ของ bun.report

• เมื่อลองแยกดูว่า URL ถูกเข้ารหัสอย่างไร:
  • แพลตฟอร์ม : อักขระตัวเดียวที่บอกแพลตฟอร์ม เช่น w คือ x86_64 Windows, M คือ aarch64 macOS
  • ซับคอมมานด์ : อักขระตัวเดียวที่แสดงซับคอมมานด์ เช่น bun test, bun install, bun run
  • คอมมิต SHA : คอมมิต SHA ของ Bun เวอร์ชันปัจจุบัน ใช้ภายหลังเพื่อดึง debug symbols
  • Feature Flags : ตัวบ่งชี้ API และความสามารถที่ถูกใช้ก่อน Bun จะแครช
  • ที่อยู่ stack trace : address ที่คำนวณไว้ก่อนหน้านี้
  • ประเภทแครช : อักขระตัวเดียวที่ระบุประเภทของแครช
  • ข้อความแครช : ข้อความของแครช ซึ่งมีรูปแบบต่างกันไปตามประเภท

VLQ นั้นสนุก

• เพื่อให้ URL สั้นในระดับที่เหมาะสม address ของ stack trace จะถูกเข้ารหัสด้วยตัวเลข base64 variable-length quantity
• ตัวเลขขนาดเล็กสามารถเข้ารหัสด้วยอักขระน้อยกว่า ขณะเดียวกันก็ยังรองรับการเข้ารหัสตัวเลขขนาดใหญ่ได้
• เป็นเทคนิคเดียวกับที่ใช้เก็บเลขบรรทัดใน JavaScript source maps

"Feature" คืออะไร?

• URL ยังเข้ารหัสจำนวนเต็ม 64 บิต ซึ่งแต่ละบิตสอดคล้องกับการใช้งานความสามารถเฉพาะของ Bun
• flags เหล่านี้ให้เบาะแสเกี่ยวกับ API และระบบที่อาจนำไปสู่แครช
• compile-time metaprogramming ของ Zig ช่วยให้สร้าง bitfield นี้ได้ง่าย
• มีคอนเทนเนอร์ของตัวแปร global สำหรับติดตามความสามารถอยู่แล้ว
• สามารถใช้ std.meta เพื่อวนผ่านรายการความสามารถและสร้างลิสต์ได้
• จากนั้นก็สร้าง packed struct ที่อนุมานแบบไดนามิกเพื่อใช้หนึ่งบิตต่อหนึ่งความสามารถ

สิ่งนี้เทียบกับ core dump อย่างไร?

• core dump มีข้อมูลมากกว่ามาก แต่ไฟล์ใหญ่ ต้องมี debug symbols จึงจะมีประโยชน์ และอาจมีข้อมูลอ่อนไหวหรือข้อมูลลับจำนวนมาก
• จึงต้องการหลีกเลี่ยงความเป็นไปได้ที่จะส่งซอร์สโค้ด JavaScript/TypeScript, ตัวแปรสภาพแวดล้อม หรือข้อมูลสำคัญอื่น ๆ ไปพร้อมรายงาน
• นี่คือเหตุผลที่ส่งเฉพาะ stack trace ของ Zig/C++ และรายละเอียดอื่น ๆ เพียงเล็กน้อย
• แทนที่จะส่งทุกอย่างเป็นค่าปริยาย แนวทางนี้จะส่งเฉพาะสิ่งที่จำเป็นต่อการวินิจฉัยปัญหา (น่าจะ) เท่านั้น

เดโม

• มีเว็บแอปเล็ก ๆ สำหรับทดสอบตัวรายงานแครชให้ใช้ได้บนหน้าแรกของ bun.report
• หากเพิ่ม /view ต่อท้าย URL ของรายงานแครช จะมาถึงหน้านี้

Bun กำลังรับสมัครงานในซานฟรานซิสโก

• หากสนใจโปรเจ็กต์แบบนี้ ตอนนี้กำลังเปิดรับวิศวกรที่ซานฟรานซิสโก
• กำลังมองหาวิศวกรระบบที่จะช่วยสร้างอนาคตของ JavaScript

ความเห็นของ GN+

• วิธีส่งรายงานแครชที่ประกอบด้วยเฉพาะข้อมูลขั้นต่ำที่จำเป็น แทนการส่งไฟล์ crash dump ทั้งก้อนซึ่งอาจมีข้อมูลอ่อนไหวอย่างข้อมูลส่วนตัว ดูเป็นแนวทางที่ดี

• เมื่อเทียบกับ core dump ข้อดีคือให้ข้อมูลที่จำเป็นได้ด้วยขนาดเล็กกว่ามาก แต่ก็อาจมีข้อเสียคือข้อมูลสำหรับดีบักอาจไม่เพียงพอ อย่างไรก็ตาม ข้อเสียนี้น่าจะพอชดเชยได้ เพราะสามารถขอข้อมูลเพิ่มเติมจากผู้ใช้ตามความจำเป็น

• ไอเดียการเข้ารหัส address ของ stack trace ด้วย VLQ น่าประทับใจ เป็นวิธีที่มีประสิทธิภาพในการส่งข้อมูลจำนวนมากด้วยขนาดเล็ก และยังน่าสนใจที่เป็นเทคนิคเดียวกับที่ใช้ใน JavaScript source maps

• โดยรวมแล้วดูเหมือนว่ามีการคิดอย่างรอบคอบและมีไอเดียสร้างสรรค์มากมายอยู่ในงานออกแบบระบบรายงานแครชนี้ และน่าจะช่วยปรับปรุงทั้งความเสถียรและการใช้งานของ Bun ได้มากผ่านรายงานแครชจริง

• หากต้องการข้อมูลเพิ่มเติมที่ไม่มีอยู่ในรายงานพื้นฐาน ผู้ใช้ก็น่าจะต้องทำความเข้าใจและกรอกข้อมูลของแต่ละฟิลด์ในรายงานแครชด้วยตนเอง ซึ่งอาจยากสำหรับผู้ใช้ที่ไม่ใช่ระดับสูง จึงน่าลองพิจารณาวิธีปรับปรุงให้ใช้งานเป็นมิตรกับผู้ใช้มากขึ้น