If it's in the signature, is it possible to give Bugzilla a signature like `[@ * | TrueTypeFontMetricsBuilder::GetBlackBox]` to get all the reasons? And then optionally/additionally to populate this data into crash stop like "30/30 are uaf, 2/32 are bad hardware"?
On Thu, Feb 2, 2023 at 8:53 AM Chris H-C <[email protected]> wrote: > > 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. -- 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/CADua4_u_Xq3%3DrGMgjL_ZUQHciGfCvhs9hJLW0eJRQqiuLWfxDg%40mail.gmail.com.
