Repository navigation
[Question] Safety of calling sentry_close(); in on_crash_callback #1054
Description
Description
I have a game server that create instances for players, I can't garantee that the instance will be up again at any point. Therefore I can't rely on sentry sending the crashs logs on the next startup.
So I'm sending the crash log as an event in the on_crash_callback like this:
static sentry_value_t on_crash_callback(const sentry_ucontext_t* uctx, sentry_value_t event, void* closure)
{
(void)uctx;
(void)closure;
sentry_event_value_add_stacktrace(event, NULL, 0);
sentry_capture_event(event);
sentry_close();
// tell the backend to retain the event
return event;
}Its working but I'm not sure if this can cause some problem. I know the recommendation is first write the dump in the disk and then send it, but I have different game instances spawning all the time. So if there is a better way to do this I would love to know.
Activity
supervacuus commentedon Oct 21, 2024
Hi @conde2!
Yes, it can cause problems, particularly on Linux, where the
on_crashhook is executed from the signal handler. We documented this here:In your example, you "close" the SDK and then proceed to run the crash handler, which would require a non-closed SDK. You would have to free the event and return a null value as described in the docs: https://docs.sentry.io/platforms/native/configuration/filtering/#using-on_crash.
But even then,
sentry_capture_event()andsentry_close()would call and trigger code unsafe to call from a signal handler, leading to dead-locks (essentially stuck crashed instances) and other hard-to-debug events (even if it might "work" now in your tests).You do not state what OS you run on or which backend you use. If you use the
crashpadbackend, crashes will be sent immediately, not at the next start, because there is an external crash monitor, which would bind the sending of the crash to the running instance.But even if you use
breakpadorinproc, you could share the database path between your instances. The database path is multi-process safe via a file lock and crashes from a previous run should be picked up and sent by any process reading that database path. If sharing is impossible, I recommend using thecrashpadbackend.