▲

GN⁺: Bun의 새로운 크래시 리포터

 (bun.sh)
2P by neo 23일전 | favorite | 댓글과 토론

Bun의 새로운 Crash Reporter

  • Bun v1.1.5에서는 Zig과 C++을 위한 새로운 크래시 리포트 형식을 만듦
  • 크래시 리포트는 개인 정보가 전혀 없는 약 150바이트 URL에 들어감

왜 OS 크래시 리포터를 사용하지 않는가?

  • macOS 같은 일부 OS는 내장 크래시 리포터가 있지만, 보통 디버그 심볼을 애플리케이션과 함께 제공해야 함
  • Linux용 디버그 심볼은 약 30MB, macOS는 약 9MB
  • Windows에서 .pdb 파일은 250MB 이상
  • Bun의 모든 설치 파일에 추가하기에는 너무 큰 용량임
  • 하지만 디버그 심볼이 없으면 크래시 정보가 매우 제한적이고, ASLR로 인해 모든 함수 주소가 쓸모없게 됨

새로운 크래시 리포터

  • Bun v1.1.5에서는 크래시나 패닉이 발생하면 메시지를 출력함
  • bun.report 링크를 클릭하면 스택 트레이스가 URL에 인코딩된 사전 작성된 GitHub 이슈 양식으로 리다이렉션됨

주소를 유용하게 만들기

  • 함수 주소는 보안상의 이유로 랜덤화된 오프셋을 포함한 애플리케이션 코드가 로드되는 메모리의 포인터
  • 트릭은 단순히 바이너리의 기본 주소에서 주소를 빼는 것
  • 각 플랫폼마다 다른 API가 있어 실제로는 이 함수가 훨씬 더 복잡함
  • 결과 주소에는 여전히 이미지에 대한 오프셋이 포함되어 있음
  • 더 짧은 URL을 인코딩하기 위해 이 오프셋은 제거되지만 remapping하기 전에 다시 추가해야 함

bun.report의 URL 구조

  • URL이 어떻게 인코딩되었는지 분석해 보면:
    • 플랫폼 : 플랫폼을 나타내는 단일 문자. w는 x86_64 Windows, M은 aarch64 macOS 등
    • 서브커맨드 : bun test, bun install, bun run 등의 서브커맨드를 나타내는 단일 문자
    • 커밋 SHA : 현재 Bun 버전의 커밋 SHA. 나중에 디버그 심볼을 가져오는 데 사용됨
    • Feature Flags : Bun이 크래시되기 전에 사용된 API와 기능에 대한 표시
    • 스택 트레이스 주소 : 앞서 계산된 주소
    • 크래시 타입 : 크래시 유형을 나타내는 단일 문자
    • 크래시 메시지 : 크래시의 메시지로 타입에 따라 형식이 다름

VLQ는 재미있다

  • URL을 적당히 짧게 유지하기 위해 스택 트레이스 주소는 base64 가변 길이 수량 숫자를 사용하여 인코딩됨
  • 작은 숫자는 더 적은 문자로 인코딩할 수 있으면서도 여전히 큰 숫자를 인코딩할 수 있게 해줌
  • JavaScript 소스 맵에서 행 번호를 저장하는 데 사용되는 것과 동일한 기술

"Feature"는 무엇인가?

  • URL은 또한 각 비트가 Bun의 특정 기능 사용 여부에 해당하는 64비트 정수를 인코딩함
  • 이러한 플래그는 크래시를 이끌 수 있는 API와 시스템에 대한 힌트를 제공함
  • Zig의 컴파일 타임 메타프로그래밍은 이 비트필드를 쉽게 만들 수 있게 해줌
  • 기능 추적을 위한 전역 변수의 컨테이너가 이미 있었음
  • std.meta를 사용하여 기능 목록을 반복하고 리스트를 만들 수 있음
  • 그런 다음 기능당 하나의 비트를 사용하도록 동적으로 파생된 팩 구조체를 만들 수 있음

이것은 코어 덤프와 어떻게 비교되는가?

  • 코어 덤프에는 훨씬 더 많은 정보가 있지만 크기가 크고, 디버그 심볼이 있어야 유용하며, 잠재적으로 민감하거나 기밀 정보를 많이 포함함
  • JavaScript/TypeScript 소스 코드, 환경 변수 또는 기타 중요한 정보를 보고서에 보낼 가능성을 피하고 싶었음
  • 이것이 Zig/C++ 스택 트레이스와 몇 가지 다른 세부 정보만 보내는 이유임
  • 모든 것을 기본적으로 보내는 대신 이 접근 방식은 (아마도) 문제를 진단하는 데 필요한 것만 보냄

데모

  • 크래시 리포터를 테스트할 수 있는 작은 웹앱을 bun.report 홈페이지에서 사용할 수 있음
  • 크래시 리포트 URL 끝에 /view를 추가하면 이곳에 도착함

Bun은 샌프란시스코에서 채용 중

  • 이와 같은 프로젝트에 관심이 있다면 샌프란시스코에서 엔지니어를 채용하고 있음
  • JavaScript의 미래를 만드는 데 도움이 될 시스템 엔지니어를 찾고 있음

GN+의 의견

  • 개인 정보 등 민감한 정보를 포함할 수 있는 크래시 덤프 파일 전체를 보내는 대신 최소한의 필요한 정보만으로 구성된 크래시 리포트를 보내는 방식은 좋은 접근법으로 보입니다.

  • 코어 덤프에 비해 훨씬 적은 용량으로 필요한 정보를 제공할 수 있는 것은 장점이지만, 디버깅에 필요한 정보가 부족할 수 있다는 단점도 있을 것 같네요. 필요에 따라 사용자에게 추가 정보를 요청할 수 있다는 점에서 이런 단점은 어느정도 커버할 수 있겠죠.

  • VLQ를 이용해 스택 트레이스 주소를 인코딩하는 아이디어가 인상적이에요. 작은 크기로 많은 정보를 전달할 수 있는 효율적인 방법이네요. JavaScript 소스맵에서 사용되는 기술이라니 재미있는 활용 사례인 것 같아요.

  • 전체적으로 크래시 리포팅 시스템 설계에 많은 고민과 창의적인 아이디어가 녹아 있는 것 같아요. 실제 크래시 리포트를 통해 Bun의 안정성과 사용성 개선에 크게 기여할 수 있을 것 같네요.

  • 기본 리포트에서는 제공되지 않는 추가 정보가 필요한 경우 사용자가 직접 크래시 리포트의 각 필드에 대한 정보를 파악하고 제공해야 할 것 같은데, 고급 사용자가 아니라면 이해하기 어려울 수도 있겠어요. 이를 사용자 친화적으로 개선할 수 있는 방안도 고려해 볼만 합니다.