Reporting Unrecovered Panics

Aperta
  • Qualcosa non va?
#968 3 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
go
Ambito
observability-sre

Direzione di ricerca

Inizia esaminando l’inizializzazione dell’SDK in sentry.Init e la chiamata differita a sentry.Flush, quindi analizza come Go scrive su stderr le tracce dei panic non recuperati prima della terminazione del processo. L’issue non identifica file, test o un’implementazione definita; il lavoro sarebbe completato quando sarà stato concordato un design e sarà stato verificato che i panic non recuperati delle goroutine vengano segnalati senza dipendere dai core dump.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Go
Stelle
1.1k
Fork
264
Merge medio
2g 6h
PR unite (30g)
11

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di getsentry/sentry-go

Tutte le issue di getsentry/sentry-go

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.