crash in CascadeRuleEnumFunc

RESOLVED DUPLICATE of bug 1007089

Status

()

--
critical
RESOLVED DUPLICATE of bug 1007089
4 years ago
a year ago

People

(Reporter: mconley, Unassigned)

Tracking

({crash})

unspecified
crash
Points:
---

Firefox Tracking Flags

(firefox46 affected, firefox47 affected, firefox48 affected, firefox49 ?, firefox-esr38 affected, firefox-esr45 affected, thunderbird_esr38 affected, thunderbird_esr45 affected)

Details

(crash signature)

Attachments

(1 attachment)

(Reporter)

Description

4 years ago
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
(Reporter)

Comment 1

4 years ago
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
Last Resolved: 4 years ago
Resolution: --- → INCOMPLETE

Comment 2

4 years ago
¡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)
(Reporter)

Comment 3

4 years ago
(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 → ---

Comment 4

3 years ago
¡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
https://crash-stats.mozilla.com/report/list?signature=CascadeRuleEnumFunc&range_value=7&range_unit=days&date=2016-04-28
Blocks: 1219672
status-firefox46: --- → affected
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox49: --- → ?
status-firefox-esr38: --- → affected
status-firefox-esr45: --- → affected
status-thunderbird_esr38: --- → affected
status-thunderbird_esr45: --- → affected
Whiteboard: ShutDownKill
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
No longer blocks: 1219672
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
Last Resolved: 4 years ago3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1007089
(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... ;-)
Created attachment 8746898 [details]
2016-04-29 04_17_45-Submitted Crash Reports - Nightly (Build 20160428030218).png
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.