BugSplat now includes local variables and function arguments for our Windows Native, Unity, and Unreal C++ integrations. By including local variables and function arguments, we can provide another level of contextual information about the cause of your crash. This new feature may help reduce or eliminate the need to debug a crash report on your local development machine.
BugSplat can now (as of 23-August-2019) create an issue in Github issues from any crash report or StackKey. Github Issues is a popular issue/bug tracker used by teams everywhere in conjunction with their Github accounts. You can learn more about Github issues here.
Welcome to our series of blog posts about all the nitty-gritty details that go into building a great debug experience at scale. Today, we’re looking at Symbolicator, the service that processes all native crash reports and minidumps at Sentry.
Over a year ago, we first announced support for Minidumps in Sentry, which allows you to debug crashes from applications written in languages like C, C++, Objective-C and more — regardless of whether you’re targeting Windows, macOS, Linux, iOS, or Android.
Crash reporting can alter the balance between support and development, and swing it in your favor! Sure "literally" is an overused term. But, I think it’s fair to say that “LITERALLY” nobody likes it when software crashes. Users don’t like it when the software they love using breaks. They’re left wondering what happened and how long will it be until there’s a fix.
We consider ourselves tech savvy. If you are reading this blog, you probably do too. And like us, you probably expect that computers are just supposed to work for you. However, in my experience, this close relationship we share with our machines just expands the realm of possible annoyances we encounter. Here are some easy ways to help you improve your relationship with the most important piece of equipment in your working life.
You’re in the process of creating and launching new softwareand you want it to be as stable as possible. Or, maybe your software has been running for a while, but you’re frustrated with the bug-reporting workflow in place. Either way it’s time to look for a crash reporting process that fits your application. This leads to a natural question: Should we build it? Or should we buy it?
You’re typing away on your computer, minding your own business when your application freezes. There’s that moment of panic, maybe the software’s just being slow. But no!! Alas, your window unexpectedly closes, your application has crashed. All of us have experienced this unfortunate event….unless you’re NASA.
In this tutorial, we’ll debug an iOS application with Apple’s Xcode. Xcode is a robust environment for developing and troubleshooting iOS applications. We’ll see how we can use it, alongside Raygun’s iOS Crash Reporting, to quickly address an application deficiency.
