It's quite common to use crash dumps. I run a game server, we compile our release builds with debug info and deploy them to production. Sometimes the server runs for hours before crashing so we can end up with a pretty big dump. When the server crashes, we grab the dump and the correct debug symbols and we at least get a call stack to investigate and (hopefully) come up with a reproducible case.
At a previous job, we developed a desktop application. When the application crashed it would allow the user to submit the core dump to our crash system. We would then have a crash dump + application version and we could investigate customer issues to see if there was a bug or something like out-of-memory issues.
Fairly standard practice for a lot of shops. I haven't seen it for web applications since it's mostly dynamic languages with exception handlers that ultimately trap the exceptions (e.g. sentry).
Comments
It's quite common to use crash dumps. I run a game server, we compile our release builds with debug info and deploy them to production. Sometimes the server runs for hours before crashing so we can end up with a pretty big dump. When the server crashes, we grab the dump and the correct debug symbols and we at least get a call stack to investigate and (hopefully) come up with a reproducible case.
At a previous job, we developed a desktop application. When the application crashed it would allow the user to submit the core dump to our crash system. We would then have a crash dump + application version and we could investigate customer issues to see if there was a bug or something like out-of-memory issues.
Fairly standard practice for a lot of shops. I haven't seen it for web applications since it's mostly dynamic languages with exception handlers that ultimately trap the exceptions (e.g. sentry).
Thanks for sharing. I work as a data engineer who writes Python and SQL so I never go deep.