Repository navigation
Ping thread exits on the first failed ping; the crash handler stays attached with no live reporter #17
Description
client::start spawns a thread that pings the server every server_poll (src/client.rs, the std::thread::spawn block):
if client.ping().is_err() {
break;
}If one ping fails, the thread ends and nothing reconnects. The server stops after its stale timeout when it gets no ping, then exits. The CrashHandler stays attached with an Arc<Client> whose server is gone. A later crash calls request_dump, which fails, and no minidump is written.
A stalled app triggers it: if the process is suspended or throttled for longer than the server's stale timeout (App Nap on macOS, a heavily loaded machine), the server drops the client and exits. When the app wakes, its ping fails and the thread ends for good.
Seen in a desktop app on macOS (Tauri, sentry-minidump 0.49 on minidumper-child 0.5.0): a SIGABRT after a non-unwinding panic produced a Sentry panic event but no minidump event, with the reporter long gone. Raising server_stale_timeout narrows the window but does not close it.
Suggested fix: on a failed ping, respawn the server and reconnect, or detach the crash handler so the process keeps its default crash behaviour and the app can tell the reporter is gone. Exposing the reporter's state (attached, detached, why) would let an app log it at boot and on loss.
Activity