Closed Bug 1022677 Opened 10 years ago Closed 9 years ago

crash in CascadeRuleEnumFunc

Categories

(Core :: CSS Parsing and Computation, defect)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1007089
Tracking Flags:
Tracking Status
firefox46 --- affected
firefox47 --- affected
firefox48 --- affected
firefox49 --- ?
firefox-esr38 --- affected
firefox-esr45 --- affected
thunderbird_esr38 --- affected
thunderbird_esr45 --- affected

People

(Reporter: mconley, Unassigned)

Details

(Keywords: crash)

Crash Data

Attachments

(1 file)

2016-04-29 04_17_45-Submitted Crash Reports - Nightly (Build 20160428030218).png
78.52 KB, image/png
Details
This bug was filed from the Socorro interface and is report bp-6fc9eeab-98ac-423c-90b4-64e7b2140507. ============================================================= Originally reported in bug 1007089. Here's the stack from the crashing thread: 0|0|libxul.so|CascadeRuleEnumFunc|hg:hg.mozilla.org/releases/mozilla-beta:layout/style/nsCSSRuleProcessor.cpp:9c77192752db|3269|0x0 0|1|libxul.so|nsCOMArray_base::EnumerateForwards(bool (*)(void*, void*), void*) const|hg:hg.mozilla.org/releases/mozilla-beta:xpcom/glue/nsCOMArray.cpp:9c77192752db|80|0xb 0|2|libxul.so|nsCSSRuleProcessor::RefreshRuleCascade(nsPresContext*)|hg:hg.mozilla.org/releases/mozilla-beta:layout/style/nsCSSRuleProcessor.cpp:9c77192752db|3432|0xf 0|3|libxul.so|nsCSSRuleProcessor::RulesMatching(AnonBoxRuleProcessorData*)|hg:hg.mozilla.org/releases/mozilla-beta:layout/style/nsCSSRuleProcessor.cpp:9c77192752db|3389|0xb 0|4|libxul.so|EnumRulesMatching<AnonBoxRuleProcessorData>|hg:hg.mozilla.org/releases/mozilla-beta:layout/style/nsStyleSet.cpp:9c77192752db|662|0x6 0|5|libxul.so|nsStyleSet::FileRules(bool (*)(nsIStyleRuleProcessor*, void*), RuleProcessorData*, mozilla::dom::Element*, nsRuleWalker*)|hg:hg.mozilla.org/releases/mozilla-beta:layout/style/nsStyleSet.cpp:9c77192752db|993|0x6 0|6|libxul.so|nsStyleSet::ResolveAnonymousBoxStyle(nsIAtom*, nsStyleContext*)|hg:hg.mozilla.org/releases/mozilla-beta:layout/style/nsStyleSet.cpp:9c77192752db|1499|0xd 0|7|libxul.so|nsCSSFrameConstructor::ConstructRootFrame()|hg:hg.mozilla.org/releases/mozilla-beta:layout/base/nsCSSFrameConstructor.cpp:9c77192752db|2575|0x5 0|8|libxul.so|PresShell::Initialize(int, int)|hg:hg.mozilla.org/releases/mozilla-beta:layout/base/nsPresShell.cpp:9c77192752db|1795|0x9 0|9|libxul.so|nsContentSink::StartLayout(bool)|hg:hg.mozilla.org/releases/mozilla-beta:content/base/src/nsContentSink.cpp:9c77192752db|1170|0x10 0|10|libxul.so|nsHtml5TreeOpExecutor::StartLayout()|hg:hg.mozilla.org/releases/mozilla-beta:parser/html/nsHtml5TreeOpExecutor.cpp:9c77192752db|600|0xa 0|11|libxul.so|nsHtml5TreeOperation::Perform(nsHtml5TreeOpExecutor*, nsIContent**)|hg:hg.mozilla.org/releases/mozilla-beta:parser/html/nsHtml5TreeOperation.cpp:9c77192752db|818|0x5 0|12|libxul.so|nsHtml5TreeOpExecutor::RunFlushLoop()|hg:hg.mozilla.org/releases/mozilla-beta:parser/html/nsHtml5TreeOpExecutor.cpp:9c77192752db|439|0x10 0|13|libxul.so|nsHtml5ExecutorReflusher::Run()|hg:hg.mozilla.org/releases/mozilla-beta:parser/html/nsHtml5TreeOpExecutor.cpp:9c77192752db|55|0x9 0|14|libxul.so|nsThread::ProcessNextEvent(bool, bool*)|hg:hg.mozilla.org/releases/mozilla-beta:xpcom/threads/nsThread.cpp:9c77192752db|694|0x6 0|15|libxul.so|NS_ProcessNextEvent(nsIThread*, bool)|hg:hg.mozilla.org/releases/mozilla-beta:xpcom/glue/nsThreadUtils.cpp:9c77192752db|263|0xf 0|16|libxul.so|nsNSSHttpRequestSession::internal_send_receive_attempt(bool&, PRPollDesc**, unsigned short*, char const**, char const**, char const**, unsigned int*)|hg:hg.mozilla.org/releases/mozilla-beta:security/manager/ssl/src/nsNSSCallbacks.cpp:9c77192752db|445|0xc 0|17|libxul.so|nsNSSHttpRequestSession::trySendAndReceiveFcn(PRPollDesc**, unsigned short*, char const**, char const**, char const**, unsigned int*)|hg:hg.mozilla.org/releases/mozilla-beta:security/manager/ssl/src/nsNSSCallbacks.cpp:9c77192752db|324|0xd 0|18|libnss3.so|cert_FetchOCSPResponse|hg:hg.mozilla.org/mozilla-central:security/nss/lib/certhigh/ocsp.c:e3b76b155ca4|3451|0x16 0|19|libnss3.so|ocsp_GetEncodedOCSPResponseFromRequest|hg:hg.mozilla.org/mozilla-central:security/nss/lib/certhigh/ocsp.c:e3b76b155ca4|3676|0xe 0|20|libnss3.so|CERT_CheckOCSPStatus|hg:hg.mozilla.org/mozilla-central:security/nss/lib/certhigh/ocsp.c:e3b76b155ca4|3815|0x1c 0|21|libnss3.so|CERT_VerifyCertificate|hg:hg.mozilla.org/mozilla-central:security/nss/lib/certhigh/certvfy.c:e3b76b155ca4|1216|0x16 0|22|libxul.so|mozilla::psm::CertVerifier::VerifyCert(CERTCertificateStr*, SECItemStr const*, long, long, void*, unsigned int, insanity::pkix::ScopedPtr<CERTCertListStr, &CERT_DestroyCertList>*, SECOidTag*, CERTVerifyLogStr*)|hg:hg.mozilla.org/releases/mozilla-beta:security/certverifier/CertVerifier.cpp:9c77192752db|169|0x31 0|23|libxul.so|nsNSSCertificate::GetChain(nsIArray**)|hg:hg.mozilla.org/releases/mozilla-beta:security/manager/ssl/src/nsNSSCertificate.cpp:9c77192752db|857|0x39 0|24|libxul.so|nsNSSCertificate::GetIssuer(nsIX509Cert**)|hg:hg.mozilla.org/releases/mozilla-beta:security/manager/ssl/src/nsNSSCertificate.cpp:9c77192752db|777|0x8 0|25|libxul.so|NS_InvokeByIndex|hg:hg.mozilla.org/releases/mozilla-beta:xpcom/reflect/xptcall/src/md/unix/xptcinvoke_x86_64_unix.cpp:9c77192752db|164|0x39 0|26|libxul.so|XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode)|hg:hg.mozilla.org/releases/mozilla-beta:js/xpconnect/src/XPCWrappedNative.cpp:9c77192752db|2393|0x5 0|27|libxul.so|XPC_WN_GetterSetter(JSContext*, unsigned int, JS::Value*)|hg:hg.mozilla.org/releases/mozilla-beta:js/xpconnect/src/xpcprivate.h:9c77192752db|2085|0xd 0|28|libxul.so|js::Invoke(JSContext*, JS::CallArgs, js::MaybeConstruct)|hg:hg.mozilla.org/releases/mozilla-beta:js/src/jscntxtinlines.h:9c77192752db|239|0x12 0|29|libxul.so|js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>)|hg:hg.mozilla.org/releases/mozilla-beta:js/src/vm/Interpreter.cpp:9c77192752db|532|0x1c 0|30|libxul.so|js::InvokeGetterOrSetter(JSContext*, JSObject*, JS::Value, unsigned int, JS::Value*, JS::MutableHandle<JS::Value>)|hg:hg.mozilla.org/releases/mozilla-beta:js/src/vm/Interpreter.cpp:9c77192752db|604|0xb 0|31|libxul.so|js::baseops::GetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<JSObject*>, JS::Handle<jsid>, JS::MutableHandle<JS::Value>)|hg:hg.mozilla.org/releases/mozilla-beta:js/src/vm/Shape-inl.h:9c77192752db|46|0x18 0|32|libxul.so|js::jit::DoGetPropFallback|hg:hg.mozilla.org/releases/mozilla-beta:js/src/jit/BaselineIC.cpp:9c77192752db|6316|0xa 0|33|||||0x7f7e4b87111c 0|34|libxul.so|js::types::TypeMonitorResult(JSContext*, JSScript*, unsigned char*, JS::Value const&)|hg:hg.mozilla.org/releases/mozilla-beta:js/src/jsinferinlines.h:9c77192752db|228|0x16 0|35|||||0x7f7e2125e1cb
Hrm, was a bit overzealous. bhearsum reports in [1] that this crash has gone away. [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1007089#c2
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INCOMPLETE
¡Hola Mike! Has it really gone away? I see bp-ea9d1551-c7e1-46c0-a448-9e89b2150403 in about:crashes from last couple weeks FWIW
Flags: needinfo?(mconley)
(In reply to alex_mayorga from comment #2) > ¡Hola Mike! > > Has it really gone away? > > I see bp-ea9d1551-c7e1-46c0-a448-9e89b2150403 in about:crashes from last > couple weeks FWIW Then I guess it hasn't. :)
Status: RESOLVED → REOPENED
Flags: needinfo?(mconley)
Resolution: INCOMPLETE → ---
¡Hola! Bite me again on bp-2ef3b863-8f01-4558-bd4b-5b15a2151214 Per https://crash-stats.mozilla.com/report/list?product=Firefox&signature=CascadeRuleEnumFunc 182 crashes in Release, Beta and Aurora. ¡Gracias! Crashing Thread Frame Module Signature Source 0 xul.dll CascadeRuleEnumFunc layout/style/nsCSSRuleProcessor.cpp 1 xul.dll nsCOMArray_base::EnumerateForwards(bool (*)(void*, void*), void*) xpcom/glue/nsCOMArray.cpp 2 xul.dll nsCSSRuleProcessor::CascadeSheet(mozilla::CSSStyleSheet*, CascadeEnumData*) layout/style/nsCSSRuleProcessor.cpp 3 xul.dll nsCSSRuleProcessor::RefreshRuleCascade(nsPresContext*) layout/style/nsCSSRuleProcessor.cpp 4 xul.dll nsCSSRuleProcessor::GetRuleCascade(nsPresContext*) layout/style/nsCSSRuleProcessor.cpp 5 xul.dll nsCSSRuleProcessor::HasDocumentStateDependentStyle(StateRuleProcessorData*) layout/style/nsCSSRuleProcessor.cpp 6 xul.dll SheetHasDocumentStateStyle layout/style/nsStyleSet.cpp 7 xul.dll nsStyleSet::WalkRuleProcessors(bool (*)(nsIStyleRuleProcessor*, void*), ElementDependentRuleProcessorData*, bool) layout/style/nsStyleSet.cpp 8 xul.dll nsStyleSet::HasDocumentStateDependentStyle(nsIContent*, mozilla::EventStates) layout/style/nsStyleSet.cpp 9 xul.dll PresShell::DocumentStatesChanged(nsIDocument*, mozilla::EventStates) layout/base/nsPresShell.cpp 10 xul.dll nsDocument::DocumentStatesChanged(mozilla::EventStates) dom/base/nsDocument.cpp 11 xul.dll NotifyDocumentTree dom/base/nsGlobalWindow.cpp 12 xul.dll nsGlobalWindow::ActivateOrDeactivate(bool) dom/base/nsGlobalWindow.cpp 13 xul.dll nsFocusManager::ActivateOrDeactivate(nsPIDOMWindow*, bool) dom/base/nsFocusManager.cpp 14 xul.dll nsFocusManager::ParentActivated(nsIDOMWindow*, bool) dom/base/nsFocusManager.cpp 15 xul.dll mozilla::dom::TabChild::RecvParentActivated(bool const&) dom/ipc/TabChild.cpp 16 xul.dll mozilla::dom::PBrowserChild::OnMessageReceived(IPC::Message const&) obj-firefox/ipc/ipdl/PBrowserChild.cpp 17 xul.dll mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) obj-firefox/ipc/ipdl/PContentChild.cpp 18 xul.dll mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) ipc/glue/MessageChannel.cpp 19 xul.dll mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp 20 xul.dll RunnableMethod<SoftwareDisplay, void ( SoftwareDisplay::*)(void), mozilla::Tuple<> >::Run() ipc/chromium/src/base/task.h 21 xul.dll MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc 22 xul.dll mozilla::ipc::DoWorkRunnable::Run() ipc/glue/MessagePump.cpp 23 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 24 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 25 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 26 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 27 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 28 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 29 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 30 xul.dll XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp 31 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 32 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 33 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 34 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp 35 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp 36 plugin-container.exe __tmainCRTStartup f:/dd/vctools/crt/crtw32/startup/crt0.c:255 37 kernel32.dll BaseThreadInitThunk 38 ntdll.dll RtlUserThreadStart
I don't understand why you added a dependency to bug 1219672. I think if there's anything related to shutdown aborts that should be filed as a separate bug. I also wonder if this is a different form of crash that might be fixed by bug 1258017, although that's a bit of a stretch.
Whiteboard: ShutDownKill
Actually, I'm going to go further than that. Having a single bug for all crashes in a particular signature is not useful. We should have separate bugs for different problems, and crash signatures are not a particularly good classification method. If there's a particular set of crashes with this signature that spike, that's worth a bug. Likewise, if there's a set with known steps to reproduce, that's worth a bug. Similar for a set that are a particularly large fraction of our crashes. But the problem this bug was originally filed about is essentially a duplicate of the bug that this bug was forked from, and it shouldn't become a catch-all for all crashes that happen to have this signature.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → DUPLICATE
(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #6) > I don't understand why you added a dependency to bug 1219672. I think if > there's anything related to shutdown aborts that should be filed as a > separate bug. OK, plz look here: https://crash-stats.mozilla.com/search/?product=Firefox&ipc_channel_error=ShutDownKill&_facets=signature&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#facet-signature This is one of the sigs that have "ipc_channel_error=ShutDownKill". (In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #7) > Having a single bug for all crashes in a particular signature is not useful. It's IMHO better then nothing! Because this ways the user get at least at CMC (CMO) a link to a bug where he can add a comment. > If there's a particular set of crashes with this signature that spike, > that's worth a bug. The problem is, that Mozilla don't send each day thousands of Windows shutdown bugs out, because some people decided that don't send out bugs is better then send them out without user interaction... ;-) > Likewise, if there's a set with known steps to > reproduce, that's worth a bug. Similar for a set that are a particularly > large fraction of our crashes. Steps to reproduce are known since a long time: - Use FF on Win with a page with a lot of JS; - Recognize that e.g. FF gets slow or use a lot of mem; - Shut down FF and restart it; - Go to about:crashes and recognize that the shutdown crash report wasn't send out; - Send them by clicking the report; - Now you see in CMC what was the reason why FF was so slow/used so much mem; - Be pi*sed why Mozilla.com don't give a f*ck about Windows Users! ;-) :-P
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #8) > (In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain > patch) from comment #7) > > Having a single bug for all crashes in a particular signature is not useful. > > It's IMHO better then nothing! > Because this ways the user get at least at CMC (CMO) a link to a bug where > he can add a comment. No, it's not, for the same reason that having a single bug for all crashes is not useful. It's not a useful categorization that will lead to things being fixed. > Steps to reproduce are known since a long time: > - Use FF on Win with a page with a lot of JS; > - Recognize that e.g. FF gets slow or use a lot of mem; > - Shut down FF and restart it; > - Go to about:crashes and recognize that the shutdown crash report wasn't > send out; > - Send them by clicking the report; > - Now you see in CMC what was the reason why FF was so slow/used so much mem; > - Be pi*sed why Mozilla.com don't give a f*ck about Windows Users! ;-) :-P Those aren't the steps for *this bug*. See comment 1007089. Furthermore, if you're filing bugs about problems, you should say that.
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #8) > (In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain > patch) from comment #6) > > I don't understand why you added a dependency to bug 1219672. I think if > > there's anything related to shutdown aborts that should be filed as a > > separate bug. > > OK, plz look here: > https://crash-stats.mozilla.com/search/ > ?product=Firefox&ipc_channel_error=ShutDownKill&_facets=signature&_columns=da > te&_columns=signature&_columns=product&_columns=version&_columns=build_id&_co > lumns=platform#facet-signature > > This is one of the sigs that have "ipc_channel_error=ShutDownKill". Also, if you look here: https://crash-stats.mozilla.com/signature/?date=%3E%3D2016-04-21T22%3A24%3A21.135403&date=%3C2016-04-28T22%3A24%3A21.135403&signature=CascadeRuleEnumFunc#aggregations you will see that 1 out of the 283 crashes in the past week has ShutDownKill. That's a very poor reason to commandeer a bug that's actually about some portion of the other 282 crashes to be about the 1 crash.
Oops, the URL in comment 10 doesn't quite restore all the UI; you need to add an aggregation for "ipc channel error".
Furthermore, if a ShutdownKill crash is what I think it is (a crash reporting that shutdown was too slow and we killed the process rather than letting it complete shutdown), then **for ShutdownKill crashes** the signature isn't particularly meaningful. The crash signature tells you exactly what point you were at when the crash happened. If the problem is that shutdown is taking to long and we've hung on shutdown (although I really don't understand why these are different from "shutdownhang |" crashes), then the exact point isn't useful or interesting information; what's relevant is what high-level algorithm is taking too long.
I filed bug 1268711 to make those crash reports clearer.
(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #12) > Furthermore, if a ShutdownKill crash is what I think it is (a crash > reporting that shutdown was too slow and we killed the process rather than > letting it complete shutdown), then **for ShutdownKill crashes** the > signature isn't particularly meaningful. The crash signature tells you > exactly what point you were at when the crash happened. If the problem is > that shutdown is taking to long and we've hung on shutdown (although I > really don't understand why these are different from "shutdownhang |" > crashes), then the exact point isn't useful or interesting information; > what's relevant is what high-level algorithm is taking too long. OK, I had this discussions a lot of times within bugzilla the last months/years... For me it looks this way: The most of the devs at Mozilla use Mac-, or Linux-Systems; doesn't recognize all the problems Windows Users have... On Windows we (the users) have mostly the problem, that FF is getting slow/hangs, or use to much mem... The reason for this is (AFAIK) a "not so good" implementation of JS for Win and the Garbage Collection (in/for Win)... While these problems are not so big if you open "normal" webpages, they getting "over time" (1-2h) really big by pages that use a lot of JS (e.g. Facebook.com). So normally the goal should be to find this problems that results in needed new-starts of FF to make FF more resource lean and more stable... I recognized that FF already tells you where are the problems with JS & GC in Win: In a crash report from FF while shutdown! (ShuteDownKills) Firefox.exe tries to unload plugin-container.exe... ...and because the plugin-container.exe is f*cked up because of the "not so good" GC, the shutdown of the container crash. So normally if you analyze & fix a crasher that was created through a shutdown crash, you not just help that FF shuts down better - you furthermore make that FF use less resources and work more stable! IMHO if there wouldn't be any shutdown crashers on Windows anymore, because they all got fixed, then we would have a really recourse lean, stable FF on Windows (, again)!
(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #9) > (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #8) > > (In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain > > patch) from comment #7) > > > Having a single bug for all crashes in a particular signature is not useful. > > > > It's IMHO better then nothing! > > Because this ways the user get at least at CMC (CMO) a link to a bug where > > he can add a comment. > > No, it's not, for the same reason that having a single bug for all crashes > is not useful. It's not a useful categorization that will lead to things > being fixed. As I hope that any person that have more influence on Mozilla.com recognize it (the bug) and this will lead to a better recognition of the problem and better fixes, it seems to be at the end, not the best, but maybe the only way that is usable. ;-)
(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #9) > Furthermore, if you're filing bugs about problems, you should say that. As I said: Told the problem a lot of times! A lot of users told these Win Problems a lot of times! And FF is losing market share (I told that, too) and getting bad test results in magazines (I told that, too)... I know it isn't fun to re-do the JS & GC at Win... but...
(In reply to David Baron [:dbaron] ⌚️UTC-7 (review requests must explain patch) from comment #10) > Also, if you look here: > https://crash-stats.mozilla.com/signature/?date=%3E%3D2016-04- > 21T22%3A24%3A21.135403&date=%3C2016-04-28T22%3A24%3A21. > 135403&signature=CascadeRuleEnumFunc#aggregations > you will see that 1 out of the 283 crashes in the past week has ShutDownKill. > > That's a very poor reason to commandeer a bug that's actually about some > portion of the other 282 crashes to be about the 1 crash. If you don't send out a shut down crash of FF in Win manual, it wouldn't get send out! This is the reason why there are not many of them! My system creates at least 1 a day... but don't send them out! ~300M Windows Installs of FF should create XYZ crash reports per day that don't get send out !!! The reason that this crashes don't get send out is, that some other folks decides, that Mozilla will not send out crashes without user interaction! So normally _NO_ "ShutDownKill" will get send out ever !!!
I attach you a screenshot to make this prob a little bit more visible... ;-)
If you want things to be fixed, please stick to one issue per bug.
Already done 2015-10-29 17:32:11 CET: https://bugzilla.mozilla.org/show_bug.cgi?id=1177121#c24 A preselected option in "about:preferences#advanced" -> "Data Choices" named something like "Send out all pending Crash Reports when restarting Firefox" only in Nightly-Builds should do it to get some "good" stats about shutdown-crashes of Win Nightly Users... ...should come a lot new "topcrasher-win" up... ...after that it can be extended "step by step" to Dev-Edition and then Beta-Version... But nothing happened since ~6 month ... ...should I do now nothing and wait the next years till someone recognize it again... ...or should I keep updating bug 1219672? ;-)
IMHO it can look like this: - Adding a sub-checkbox to "Enable Crash Reporter" named "Auto-Send pending reports in background; (Only in Nightly now; maybe in 4 weeks in Aurora; then in 8 weeks in Beta.) - Select this sub-checkbox by default; - Add to the routine that check the option and send "Nightly Health Reports" a part that check the option of "Auto-Send" and send (if exist) 1 pending report with each Health Report. This would be my suggestion/solution for now...
If you want things to be fixed, please stick to a limit of one issue per bug.
I read ATM you comment 1219672#c36... As mentioned before: I never expected that this bug will be fixed at once! ;-) IMHO we can close bug 1219672 with "Wontfix" if the crash reports get send out in future and the devs can see the problems in CMC.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: