For me, I interact with crashes mostly through Bugzilla. This means that the signature, to me, is the best place for any piece of important character about the crash. For the types of crashes that permit it, I'd like to see the trend of "put that in the sig" continue.
The next place I look at for context is the Crash Data section in BMO where Crash Stop[1] obligingly fills in a lot of helpful info. If we can't put the data in the sig, maybe we can put it there? Otherwise, field/annotation away. I'll find it eventually (or at the very least someone will point it out to me once I've missed it). I'm just happy we'll have this information as it'll help me out, wherever it is displayed. :chutten [1]: https://github.com/mozilla/crash-stop-addon On Thu, Feb 2, 2023 at 8:14 AM Gabriele Svelto <[email protected]> wrote: > [cross-posting to dev-platform] > > Hello everybody, > last year we replaced the tool used to extract stacks and additional > information from crashes with a new Rust-based implementation. One of > the goals behind the change was extending it over the legacy tool and > surfacing richer information about crashes. > > As we've implemented a few different analyses we were left wondering > what would be the best way to surface this information in crash reports. > Here's a few things we can detect now: > > * We accessed a dead object (i.e. the crash is an UAF) > * We jumped into a dead object (same as above, but we were probably > going through the vtable or a function pointer) > * The crash was a NULL pointer access even though it might not look like > one (e.g. it was NULL plus a fixed offset, like when reading a field of > a structure) > * The crash was cause by bad hardware (corrupted data on disk, bad > memory with stuck bits, etc...) > > And here's a few more we'll be able to detect soon: > > * The crash was caused by the data being misaligned when accessed (this > happens sometimes with SIMD/vector instructions) > * The crash is impossible - likely caused by a CPU bug (e.g. the crash > is a segmentation fault but the crashing instruction doesn't access memory) > * The crash is a stack overflow (these have a specific crash reason on > Windows, but not on macOS and Linux) > > So the question is, where would you like to see this data? In some case > we already surface some of it in the crash signature, see this crash as > an example: > > > https://crash-stats.mozilla.org/report/index/2ccae112-2e4e-4904-ba18-aaba60230202 > > This isn't the best way for all type of crashes though, for example > accesses to dead objects can't be detected all the time so putting that > information in the signature would bucket crashes in unwanted ways > depending on what was in the object. > > Another possibility is to add a new field to the crashes that would then > be shown as a column when looking at a list of crash reports (something > like the crash reason, but more rich since we know more about the crash). > > What do you think? What would help you more when looking at crashes? > > Gabriele > > -- > You received this message because you are subscribed to the Google Groups " > [email protected]" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/93d0d34d-3d15-bcf1-22b2-0963878b73bf%40mozilla.com > . > -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/CAMPhgK9g-O3h88XCj%3DsG5i2%2B4noquvAVjGCJYWTzFTj_2uRTrw%40mail.gmail.com.
