Crash Reporting


I get the feeling that some people wonder what goes in the crash reporting. I’ll just spell it out here so I can just say, read my blog. (side note: I used to hate that when trying to strike a conversation with bloggers, but it’s better than just saying I copy stuff when I don’t want to get into details because simplifying stuff just easier to do when people don’t care enough for the details.)

So most of what goes in my crash reporting ( ) is based on :, some of the discussions that go on in #crashkill / ( ) and my reading up on various bugs.

If you look at the site and the crash signatures, you’ll notice that a good chunk of them have crash signatures based on specific memory locations. The problem with that is that they are not all the same crashes in some cases, and not only that they are not meaningful to the engineers. The next meaningful line has to be extrapolated from the crash signatures. Looking at the stack some of the stacks are pretty much the same, but just have a slightly off memory location that it crashed in. Most likely they are the same crash stack. The bugs have to be created from those signatures if they are new, and sometimes if they only have a small percentage, it might just be worth it to track the signature for a bit rather tan write a bug for it. Based on the stack, I do attempt to try to reproduce the issue at times, esp if it’s a high frequency crash. I also track resolved issues for a while as well as report when a crash has been resolved even though it’s in the list (you’ll see some crash signatures that have a strike through for those). Lastly, I occasionally do follow ups in bugs, see what bugs might be related to each other and then report and give a call out to the highlights in the meetings so other people might be able to take action on the top crashers. And that all takes some time.

So ya. You can call it copying the stuff. I would prefer to say, copying stuff with some TLC.