By the way, this is the kiss of death query. MOZ_CRASH, start up, in safe mode. We’re basically forcing these people away. There is nothing they can do even if they really want to run Firefox (assuming this is a persistent start up crash, of course.) The numbers aren’t high, and majority of them are OOMs, but I still feel like this query should never have things in it. (Randomly picked 8 seconds, I know that some consider it a start up crash if it crashes much later than that.)
https://crash-stats.mozilla.com/search/?product=Firefox&moz_crash_reason=%21__null__&uptime=%3C8&safe_mode=__true__&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature It’s also interesting to extend the query to specify the amount of memory the machine has - how do we get an OOM on startup when the users have 2GB of RAM? — - Milan > >> On May 31, 2016, at 2:22 , Nicholas Nethercote <n.netherc...@gmail.com> >> wrote: >> >> Hi, >> >> Here is a crash-stats search that shows all the crash reports in the >> past 7 days that have a "MozCrashReason" field -- which means they >> were triggered by MOZ_CRASH or MOZ_RELEASE_ASSERT -- faceted (i.e. >> aggregated) by that field: >> >> https://crash-stats.mozilla.com/search/?product=Firefox&_facets=moz_crash_reason&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=moz_crash_reason#facet-moz_crash_reason >> >> I've included the output below. (Apologies if it gets munged when the >> email is processed; just click on the link above to see the live >> list.) >> >> #1 by a long way is shutdown hangs. No great surprise. >> >> #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument >> given. These are mostly OOMs, though there are a few others in there. >> These ones should be annotated so they show up separately. >> >> From #3 down we have smaller numbers, but many of them are still >> non-trivial, and a lot of them are probably indicative of problems >> that are very easy to fix if the right person sees them. Please take a >> look through the list to see if any of them are familiar to you. >> >> (If you're wondering why I made this search... I've found that many >> crash reports lack enough data to be actionable -- especially those >> involving crashes caused by bad memory accesses. So it's worth >> focusing to some degree on the crash reports that are more likely to >> be actionable, and places where we deliberately abort are an obvious >> case.) >> >> Nick >> >> >> 1 MOZ_CRASH(Shutdown too long, probably frozen, causing a crash.) >> 129715 9.92 % >> 2 MOZ_CRASH() 25987 1.99 % >> 3 MOZ_CRASH(GFX: Unable to get a working D3D9 Compositor) >> 2104 0.16 % >> 4 MOZ_CRASH(Unexpected error during FakeBlack creation.) 1679 0.13 % >> 5 MOZ_CRASH(IPC FatalError in the parent process!) 783 0.06 % >> 6 MOZ_RELEASE_ASSERT(pi->mInternalRefs < pi->mRefCount) (Cycle >> collector found more references to an object than its refcount) 509 >> 0.04 % >> 7 MOZ_RELEASE_ASSERT(!mDoingStableStates) 466 0.04 % >> 8 MOZ_CRASH(Bogus tree op) 459 0.04 % >> 9 MOZ_RELEASE_ASSERT(sAliveDisplayItemDatas && >> sAliveDisplayItemDatas->Contains(aData)) 263 0.02 % >> 10 MOZ_CRASH(Using observer service off the main thread!) 223 0.02 % >> 11 MOZ_RELEASE_ASSERT(!mSkipRequest.Exists()) (called mid-skipping) >> 222 0.02 % >> 12 MOZ_CRASH(GFX_CRASH) 215 0.02 % >> 13 MOZ_RELEASE_ASSERT(NS_IsMainThread()) 131 0.01 % >> 14 MOZ_RELEASE_ASSERT(aMsg.priority() == >> IPC::Message::PRIORITY_NORMAL) 120 0.01 % >> 15 MOZ_RELEASE_ASSERT(aRefCount != 0) (CCed refcounted object has zero >> refcount) 113 0.01 % >> 16 MOZ_RELEASE_ASSERT(!mAudio.HasPromise()) (No duplicate sample >> requests) 110 0.01 % >> 17 MOZ_RELEASE_ASSERT(ok) 105 0.01 % >> 18 MOZ_CRASH(GFX: D3D11 timeout) 99 0.01 % >> 19 MOZ_CRASH(invalid process aSelector) 73 0.01 % >> 20 MOZ_CRASH(We lost the following char message) 58 0.00 % >> 21 MOZ_CRASH(Unhandlable OOM while clearing document dependent slots.) >> 53 0.00 % >> 22 MOZ_CRASH(TODO: sourcebuffer was deleted from under us) 52 >> 0.00 % >> 23 MOZ_RELEASE_ASSERT(prio == IPC::Message::PRIORITY_NORMAL || >> NS_IsMainThread()) 51 0.00 % >> 24 MOZ_CRASH(GFX: Failed to update reference draw target after device >> reset) 45 0.00 % >> 25 MOZ_RELEASE_ASSERT(isSystem) 42 0.00 % >> 26 MOZ_CRASH(Crash creating texture. See bug 1221348.) 41 0.00 % >> 27 MOZ_CRASH(sandbox_init() failed) 41 0.00 % >> 28 MOZ_CRASH(Unable to get a working D3D9 Compositor) 37 0.00 % >> 29 MOZ_CRASH(GFX: Invalid D3D11 content device) 33 0.00 % >> 30 MOZ_CRASH(Initial length is too large) 30 0.00 % >> 31 MOZ_CRASH(Could not start cubeb stream for MSG.) 27 0.00 % >> 32 MOZ_CRASH(IPC message size is too large) 25 0.00 % >> 33 MOZ_RELEASE_ASSERT(mWorkerLoopID == MessageLoop::current()->id()) >> (not on worker thread!) 25 0.00 % >> 34 MOZ_RELEASE_ASSERT(!mInWriteTransaction) 24 0.00 % >> 35 MOZ_CRASH(NativeKey tries to dispatch a key event on destroyed >> widget) 23 0.00 % >> 36 MOZ_RELEASE_ASSERT(((bool)(!!(!NS_FAILED_impl(rv)))) && thread) >> (Should successfully create image decoding threads) 23 0.00 % >> 37 MOZ_RELEASE_ASSERT(aInAndOutListener) (can not perform CORS checks >> without a listener) 23 0.00 % >> 38 MOZ_CRASH(Unknown unit type?) 18 0.00 % >> 39 MOZ_RELEASE_ASSERT(!mVideo.mDecodingRequested) (Reset must have >> been called) 17 0.00 % >> 40 MOZ_RELEASE_ASSERT(msg->size() < IPC::Channel::kMaximumMessageSize) >> 17 0.00 % >> 41 MOZ_RELEASE_ASSERT(!r.IsEmpty()) 14 0.00 % >> 42 MOZ_RELEASE_ASSERT(!r->IsEmpty()) 13 0.00 % >> 43 MOZ_RELEASE_ASSERT(CheckDocTree()) 12 0.00 % >> 44 MOZ_RELEASE_ASSERT(mDestroyCalled) 11 0.00 % >> 45 MOZ_RELEASE_ASSERT(!!compositor) 10 0.00 % >> 46 MOZ_RELEASE_ASSERT(MessageLoop::current() == mWorkerLoop) 10 >> 0.00 % >> 47 MOZ_RELEASE_ASSERT(sDebugOwningThread != currentThread) 10 >> 0.00 % >> 48 MOZ_RELEASE_ASSERT(SizeOfEntryStore(CapacityFromHashShift(), >> mEntrySize, &nbytes)) 8 0.00 % >> 49 MOZ_CRASH(Accessing the Subject Principal without an AutoJSAPI on >> the stack is forbidden) 7 0.00 % >> 50 MOZ_CRASH(Initial entry store size is too large) 7 0.00 % >> _______________________________________________ >> 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
