-
-
Notifications
You must be signed in to change notification settings - Fork 168
Closed
Description
Minimal code:
setup_sentry(); // with: (1) "panic" integration (2) "debug_images" integration
sentry::capture_error(some_error);
Then the capture_error will stuck forever if it panics inside the handlers of sentry error capturing. For example, with gimli-rs/findshlibs#70, the debug_images integration's crate::debug_images() will panic. In that case the code above will stuck forever.
The reason is that:
- Our code call
sentry::capture_error(some_error);. sentry start handling the first event (say, the manually-called event) - sentry calls some code that panics (e.g. the debug_images integration in this example)
- then this
sentry::capture_error(some_error);panics - then I guess the global default sentry panic handler is triggered because of this panic. now sentry is handling a second event (say, the panic event)
- then I observe stucking forever inside the
lazy_staticwhich callscrate::debug_images(). This is probably caused by how lazy_static works (if it panics, future calls will stuck forever). However, even if it does not stuck, the new call will panic again, then trigger third event, etc. Then sentry will be handling errors recursively infinitely...
Why this is a bit critical
The root cause in this specific example is gimli-rs/findshlibs#70, so I expect to see something like "findshlib panics". However, with sentry, I see the app stuck forever, without any error reports.
Metadata
Metadata
Assignees
Labels
No labels