Reporting Unrecovered Panics

オープン
  • 何か問題がありますか？
#968 コメント 3 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
5/5
見積もり時間
1週間以上
初心者へのやさしさ
25/100
issue の種類
機能追加
明瞭さ
説明が足りない
活発さ
停滞
技術スタック
go
領域
observability-sre

調査の方向性

まず sentry.Init での SDK の初期化と、遅延実行される sentry.Flush 呼び出しを確認し、次にプロセス終了前に Go が回復されていない panic のトレースを stderr に書き込む仕組みを調査してください。この issue ではファイル、テスト、確定した実装は特定されていません。完了条件は、合意された設計があり、回復されていない goroutine の panic が core dump に依存せず報告されることを検証できることです。

索引モデルが issue の本文から書いたものです。

説明

Errors Feature Go
Problem Statement

The current SDK will not report a panic if it isn't caught in a recover. The following example does not report any errors to Sentry. Panics and unhandled crashes are arguably the highest value errors an SRE would want to monitor and alert on in a production environment.

By default, Go will print the panic trace to stderr before exiting, but there is no opportunity for another go routine to recover the panic before the process terminates (note the absence of "Main exiting" in the output below).

There are a whole host of reasons a go program could panic, from data races to nil pointer dereferences, and there does not seem to be a good way to enforce panic recovery in every single go routine a developer might add to the codebase.

package main

import (
	"log"
	"time"
	"github.com/getsentry/sentry-go"
)

func main() {
	// Initialize Sentry SDK
	err := sentry.Init(sentry.ClientOptions{
		Dsn: "https://[email protected]/your-project",
		Debug: true,
	})
	if err != nil {
		log.Fatalf("sentry.Init: %s", err)
	}
	defer sentry.Flush(2 * time.Second)

	// Main goroutine recovery attempt (won't help)
	defer func() {
		if r := recover(); r != nil {
			log.Println("Main recovered:", r)
		}
	}()

	// Start problematic goroutine
	go func() {
		panic("goroutine panic - unrecovered")
	}()

	// Keep main alive to observe behavior
	time.Sleep(1 * time.Second)
	log.Println("Main exiting")
}

Ouputs:

...
[Sentry] 2025/02/20 16:41:01 Integration installed: GlobalTags
panic: goroutine panic - unrecovered

goroutine 24 [running]:
main.main.func2()
	/Users/chodges/go-panic/panic.go:29 +0x2c
created by main.main in goroutine 1
	/Users/chodges/go-panic/panic.go:28 +0xbc
Solution Brainstorm

Triggering a core dump is one way to get around this problem and report the error to Sentry, however that has its own set of drawbacks:

  • Exposes sensitive data
  • Generates large files which could fill the disk
  • High file I/O could compromise performance of the compute node

Another option would be to take a config option in the SDK initialization that has a file path to stderr output for the process. Then on SDK startup, it could go through the stderr output and look for panic stack traces and report them to Sentry. Parsing logs for errors is messy, but given how Golang handles unrecovered panics there is really nothing that can be done with error handling post-panic and before process termination.

主要言語
Go
スター
1.1k
フォーク
264
平均マージ
2日 6時間
マージ済み PR（30日）
11

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

getsentry/sentry-go のほかの issue

getsentry/sentry-go の issue をすべて見る

似ている issue

Go の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。