In the continuation of bug 1529792 and bug 1538948 ... we have this crash for betas 69, 70, ... where uptime is 50% <60 seconds https://crash-stats.mozilla.com/signature/?product=Thunderbird&signature=nsContentSecurityManager%3A%3AdoContentSecurityCheck&date=%3E%3D2019-07-25T00%3A00%3A00.000Z&date=%3C2019-10-25T23%3A59%3A00.000Z&_columns=date&_columns=product&_columns=version&_columns=build_id&_columns=platform&_columns=reason&_columns=address&_columns=install_time&_columns=startup_crash&_sort=-date&page=1#summary

I looked at three crashes - none of the stacks are the same

bp-764a7eae-1bb3-434f-832b-e64bf0191025

bp-cf3f7852-f3d1-41a3-98e5-aec080191025

bp-3c242270-7203-47f0-ac5f-9074a0191025
0 XUL nsContentSecurityManager::doContentSecurityCheck(nsIChannel*, nsCOMPtr<nsIStreamListener>&) dom/security/nsContentSecurityManager.cpp:874
1 XUL mozilla::dom::ClientSource::Activate(mozilla::dom::PClientManagerChild*) dom/clients/manager/ClientSource.cpp:191
2 XUL nsDocLoader::QueryInterface(nsID const&, void**) uriloader/base/nsDocLoader.cpp:186
3 XUL nsDocShell::QueryInterface(nsID const&, void**) docshell/base/nsDocShell.cpp:570
4 XUL void NS_QueryNotificationCallbacks<mozilla::net::HttpBaseChannel>(mozilla::net::HttpBaseChannel*, nsID const&, void**) netwerk/base/nsNetUtil.h:547
5 XUL nsDocShell::InterfaceRequestorProxy::GetInterface(nsID const&, void**) docshell/base/nsDocShell.cpp:12389
6 XUL mozilla::net::PrivateBrowsingChannel<mozilla::net::HttpBaseChannel>::UpdatePrivateBrowsing() netwerk/base/PrivateBrowsingChannel.h:79
7 XUL nsDocShell::GetInterface(nsID const&, void**) docshell/base/nsDocShell.cpp:673
8 XUL nsGetInterface::operator()(nsID const&, void**) const xpcom/base/nsIInterfaceRequestorUtils.cpp:21
9 XUL mozilla::net::nsHttpChannel::AsyncOpen(nsIStreamListener*) netwerk/protocol/http/nsHttpChannel.cpp:6339
10 libmozglue.dylib free memory/build/malloc_decls.h:54
11 XUL nsURILoader::OpenURI(nsIChannel*, unsigned int, nsIInterfaceRequestor*) uriloader/base/nsURILoader.cpp:840
12 XUL nsDocShell::OpenInitializedChannel(nsIChannel*, nsIURILoader*, unsigned int) docshell/base/nsDocShell.cpp:10666
13 XUL nsDocShell::DoChannelLoad(nsIChannel*, nsIURILoader*, bool) docshell/base/nsDocShell.cpp:10621
14 XUL nsDocShell::DoURILoad(nsDocShellLoadState*, bool, nsIDocShell**, nsIRequest**) docshell/base/nsDocShell.cpp:10424
15 XUL nsIZipReader::COMTypeInfo<nsIZipReader, void>::kIID
16 XUL nsIZipReader::COMTypeInfo<nsIZipReader, void>::kIID
17 XUL nsDocShell::InternalLoad(nsDocShellLoadState*, nsIDocShell**, nsIRequest**) docshell/base/nsDocShell.cpp:9603
18 CoreFoundation __CFArrayReleaseValues
19 XUL XUL@0x39267f
20 XUL nsIZipReader::COMTypeInfo<nsIZipReader, void>::kIID
21 XUL nsIZipReader::COMTypeInfo<nsIZipReader, void>::kIID
22 XUL nsIZipReader::COMTypeInfo<nsIZipReader, void>::kIID
23 XUL nsQueryActor::operator()(nsID const&, void**) const dom/ipc/nsQueryActor.h:37
24 XUL nsIZipReader::COMTypeInfo<nsIZipReader, void>::kIID
25 XUL nsCOMPtr_base::assign_from_helper(nsCOMPtr_helper const&, nsID const&) xpcom/base/nsCOMPtr.cpp:109
26 XUL nsDocShell::GetLoadURIDelegate() docshell/base/nsDocShell.cpp:2096
27 XUL addBinding.xmlnsNamespace
28 XUL nsDocShell::PerformRetargeting(nsDocShellLoadState*, nsIDocShell**, nsIRequest**) docshell/base/nsDocShell.cpp:8838
29 XUL nsTSubstring<char>::StartBulkWriteImpl(unsigned int, unsigned int, bool, unsigned int, unsigned int, unsigned int) xpcom/string/nsTSubstring.cpp:248

#1 crash for 71.0b1

Again, let's look at the reasons:
bp-764a7eae-1bb3-434f-832b-e64bf0191025 - MOZ_RELEASE_ASSERT(false) (SystemPrincipal must not load remote documents.)
bp-cf3f7852-f3d1-41a3-98e5-aec080191025 - MOZ_RELEASE_ASSERT(false) (SystemPrincipal must not load remote documents.)

So M-C added some MOZ_RELEASE_ASSERT() that triggers on certain loads. Since they are all startup crashes, maybe the crash sufferers have "strange" start pages? Hard to tell, but this is a pre-programmed crash added here:
https://hg.mozilla.org/mozilla-central/rev/f3dee38996fa#l1.31

I'm experiencing this startup crash in one of my profiles, completely breaking my profile from launching, before upgrading about a week ago it was working just fine. If anyone needs any testing or regression windows let me know. Even crashes in safe mode.

(In reply to Jorg K (GMT+1) (PTO to 5th Jan 2020, sporadically reading bugmail) from comment #2)

... Since they are all startup crashes, maybe the crash sufferers have "strange" start pages?

Do you have the stock start page, set at options > general? If not, what?
If it is not start page related, does your crash happen if you start with
thunderbird.exe -offline

I can't check since it's a startup crash. prefs.js doesn't have any interesting urls set, though, so I guess the answer is no.
Crash even occurs while launching Thunderbird in 'Work Offline' mode (and Safe Mode).

setting the var MOZ_DISABLE_NONLOCAL_CONNECTIONS to false before launching Thunderbird does launch Thunderbird fine, disabling offline mode in Thunderbird causes it to crash again.

Do you have news accounts?
Please post account descriptions from Help > Troubleshooting

I wonder if this is related to Bug 1452600 - Port |Bug 1520868 - Remove nsIChannel::Open/AsyncOpen| (Move open2 and asyncOpen2 to being the only implementaion)

The profile crashing is a News/RSS -only profile so it doesn't contain any Mail accounts.
account_rssfeeds (rss) Feeds None Normal password

(In reply to rctgamer3 from comment #8)

The profile crashing is a News/RSS -only profile so it doesn't contain any Mail accounts.
account_rssfeeds (rss) Feeds None Normal password

Thoughts?

Crashes inside https://searchfox.org/mozilla-central/rev/c61720a7d0c094d772059f9d6a7844eb7619f107/dom/security/nsContentSecurityManager.cpp#869

Crashes such as bp-253e16b0-aaf2-4280-bd2a-40abb0191217 have nsDocShell::LoadURIFromScript on the stack, so that would probably be scripts loaded in feeds (since we don't use them just about anywhere else).

If there is indeed only a feed account, with no nntp or custom start page, and no web page content is loaded prior to the crash (ie message selected) then the problem is very highly likely to be a bad favicon. The pref browser.chrome.favicons can be set to false to test, if this is reliably reproducible.

The feed favicon code tests urls by loading in a temp html element, since errors are (usually) well returned in an onError(); it could be happening there. If so, it would be a gecko issue.

(In reply to alta88 from comment #11)

If there is indeed only a feed account, with no nntp or custom start page, and no web page content is loaded prior to the crash (ie message selected) then the problem is very highly likely to be a bad favicon. The pref browser.chrome.favicons can be set to false to test, if this is reliably reproducible.

rctgamer3, is your crash reproducible enough that you can test this theory?

(In reply to Wayne Mery (:wsmwk) from comment #12)

I've set the browser.chrome.favicons pref to false in and it still crashes.

FWIW, buildid 20191212014636 = 72.0b2 had a massive spike of crashes. But rctgamer3's crashes were 72.0b1 if I have figured it out correctly.

No longer seems to crash with 73.0b2 (64-bit)

Thanks for the update.

The last nightly build to crash was 20191129063314 72.0a1, and there have been zero 73.0b1 or 73.0b2 crashes.