For example, searching for “graphics critical error” containing 0x8007000e (Windows error code for “out of memory”) leads you to a lot of crashes/bugs that are not tagged as OOM (which is OK), but clearly have some aspect of “running out of stuff” in them.
In general, it can come in handy when the info is otherwise light (e.g., “ERROR NO MINIDUMP HEADER” ones :) — - Milan > On Jun 2, 2016, at 13:17 , Milan Sreckovic <msrecko...@mozilla.com> wrote: > > If you want a treasure trove :), when it comes to graphics crashes, the > “graphics critical error” field is it. It’s a recent history of barely > avoidable crashes and error states just before the crash actually happens. > Very often the real cause of the crash happens prior to the line of code > captured in the stack trace. > > (It doesn’t necessarily make sense to search for the "graphics critical > error” existence, as too many bugs will show up, but for us it’s usually the > first step after we identify a crash to look at.) > > - Milan > > > >> On Jun 1, 2016, at 21:40 , Nicholas Nethercote <n.netherc...@gmail.com> >> wrote: >> >> I apologize for the sarcasm. I was frustrated with this comment: >> >>> I looked at the query from the first post, but it's just noise to me. If it >>> included the file that it >>> crashed from, it would suddenly be very useful, since it'd then be trivial >>> to see if there's >>> something relevant to me. >> >> but it wasn't a good way to respond. So I'll try again. >> >> Most of the results in the search identify a unique string, which *is* >> trivial to look up. And while it's true that file and/or function >> names would help refine the small number of cases where distinct >> MOZ_CRASH calls, you can also do that with a simple follow-up search >> refinement, as I showed in my previous response. The required data is >> present. I would describe the presentation as "slightly suboptimal but >> still highly usable". >> >> I've looked at a lot of crash reports recently and one thing I've >> learned is how inadequate they often are. Many are unactionable. Many >> aren't even comprehensible. In comparison, this list is a treasure >> trove, containing reports that are much more comprehensible and >> actionable than average. It's one which I intend to revisit, and I >> hope others will too. >> >> Nick >> >> >> On Thu, Jun 2, 2016 at 5:22 AM, Jeff Gilbert <jgilb...@mozilla.com> wrote: >>> It would be useful to have a dashboard that collates this information >>> better. >>> >>> PS: Sarcasm is unhelpful. >>> >>> On Tue, May 31, 2016 at 7:14 PM, Nicholas Nethercote >>> <n.netherc...@gmail.com> wrote: >>>> On Wed, Jun 1, 2016 at 11:26 AM, Jeff Gilbert <jgilb...@mozilla.com> wrote: >>>>> >>>>> Perhaps this isn't meant for me then? I looked at the query from the >>>>> first post, but it's just noise to me. If it included the file that it >>>>> crashed from, it would suddenly be very useful, since it'd then be >>>>> trivial to see if there's something relevant to me. >>>> >>>> Let's look at the top #3: >>>> >>>> >>>> 1 MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.) >>>> 129715 9.92 % >>>> >>>> If you use your favourite source code search tool to look for >>>> "Shutdown too long", you'll find that this crash is occurring in >>>> toolkit/components/terminator/nsTerminator.cpp. For example, here's a >>>> DXR link: >>>> >>>> https://dxr.mozilla.org/mozilla-central/search?q=%22Shutdown+too+long%22&redirect=false >>>> >>>> The line in question looks like this: >>>> >>>> MOZ_CRASH("Shutdown too long, probably frozen, causing a crash."); >>>> >>>> >>>> 2 MOZ_CRASH() 25987 1.99 % >>>> >>>> This one matches all calls to MOZ_CRASH() that don't provide a string >>>> parameter. Digging into these ones is slightly harder, requiring a new >>>> search for bugs that have "moz crash reason" set to "MOZ_CRASH()": >>>> >>>> https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%3DMOZ_CRASH%28%29&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-signature >>>> >>>> >>>> 3 MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) 2104 0.16 % >>>> >>>> Searching for "working D3D9 Compositor" identifies this one as coming >>>> from gfx/layers/d3d9/CompositorD3D9.cpp. >>>> >>>> >>>> And so on. Searching for strings in code is a useful technique in many >>>> situations, I recommend it! >>>> >>>> >>>> BTW, thank you to all those who have already looked through the list >>>> and mentioned existing bugs and/or filed new bugs. >>>> >>>> Nick >> _______________________________________________ >> dev-platform mailing list >> dev-platform@lists.mozilla.org >> https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
