1266673 - Assertion failure: false (contentPolicyType not supported yet), at dom/security/nsContentSecurityManager.cpp:158 (mozmill)

Status: RESOLVED WONTFIX

(Thunderbird :: General, defect)

Description

[aleth [:aleth]]

Mozmill failure on debug builds.
m-c regression window: 30c5dbcee7dd to 4feb4dd910a5

Comment 1

[Stefan Sitter [:ssitter]]

The assertion is reported for nsIContentPolicy::TYPE_IMAGE. 
Regression range per previous comment:
> https://hg.mozilla.org/comm-central/pushloghtml?fromchange=30c5dbcee7dd&tochange=4feb4dd910a5

Maybe it was regressed by Bug 1257930 <https://hg.mozilla.org/mozilla-central/rev/22521e3f311e>? If Thunderbird uses NetUtil.asyncFetch() on a channel created with nsIContentPolicy::TYPE_IMAGE this might trigger the assertion now?

Comment 2

[aleth [:aleth]]

(In reply to Stefan Sitter from comment #1)
> Maybe it was regressed by Bug 1257930
> <https://hg.mozilla.org/mozilla-central/rev/22521e3f311e>? If Thunderbird
> uses NetUtil.asyncFetch() on a channel created with
> nsIContentPolicy::TYPE_IMAGE this might trigger the assertion now?

That bug looks like it could be the cause, indeed.

Comment 3

[Jorg K (CEST = GMT+2)]

That now moved to C-B ;-(

Comment 4

[Jorg K (CEST = GMT+2)]

Currently this is reported as
Assertion failure: false (contentPolicyType not supported yet), at /builds/slave/tb-c-beta-l64-d-00000000000000/build/mozilla/dom/security/nsContentSecurityManager.cpp:142
matching
https://dxr.mozilla.org/mozilla-beta/source/dom/security/nsContentSecurityManager.cpp#142

Why does this only crash on beta (and before on Aurora when Aurora was at 48)? Did we forget to uplift something? Bug 1257930 landed on mozilla48.

Christoph, perhaps you have a tip for us.

Aleth: Why only on beta and which Mozmill test is actually failing?
http://archive.mozilla.org/pub/thunderbird/tinderbox-builds/comm-beta-linux64-debug/1466514903/comm-beta_ubuntu64_vm-debug_test-mozmill-bm125-tests1-linux64-build0.txt.gz
Looks like tests/mozmill/content-tabs/test-lwthemes.js | test_lightweight_themes_install failing on
dispatching ResetBrowserThemePreview

Is this something Richard could help us with?

Comment 5

[aleth [:aleth]]

Let's ask rkent if there's some relbranch not being updated issue.

Comment 6

[Kent James (:rkent)]

beta repo should be back to normal now, pulling from mozilla-beta  Not sure which way you think this issue is - do you have evidence that the comm-beta builds are using a different repo or revision?

Comment 7

[aleth [:aleth]]

I don't know what fixed this on c-a. It might help if one could find out when the failure stopped showing up on c-c. Since it's apparently fixed in c-a and c-c at the moment, this seems pretty low priority however.

Comment 8

[Jorg K (CEST = GMT+2)]

And our beta will just do something that isn't right? Sure, only the debug version crashes.

Last seen on C-C here on Apr 28, 2016
https://treeherder.mozilla.org/#/jobs?repo=comm-central&revision=0e1299ac02ccbd74c33a0f63099056de7319a634&selectedJob=36892
So something landed on mozilla49 that fixed the problem (branch date was Apr 25, 2016) that didn't make it back to mozilla48.

Aleth, why did you clear the NI for Christoph? He's been very helpful before, so maybe he has a tip and knows something we don't know.

Christoph, please look at comment #4.

Comment 9

[Christoph Kerschbaumer [:ckerschb]]

Why this is crashing on 48, I don't know to be honest. A Stacktrace would certainly help to figure out what's going on. In general, we converted the imageLoader to use AsyncOpen2() here [1] which landed in 49. Up to then, no image loads should have actually used asyncOpen2() and hence end up in the contentSecuritymanager. I know for a fact that TYPE_IMAGE (also TYPE_IMAGESET) did not use asyncOpen2() on mozilla-central. I don't exactly know how TB is arranged in terms of code but here are two things that might help:
* search for TYPE_IMAGE within the codebase
* provide a stacktrace of the crash 

Might actually be that Bug 1257930 regressed that, but for that to happen, there must still be a TYPE_IMAGE load happening somewhere.

[1] https://hg.mozilla.org/mozilla-central/rev/65911fba8069#l1.102

Comment 10

[Jorg K (CEST = GMT+2)]

Well, looks like bug 1257930 (landed on mozilla48) caused it and bug 1206961 (landed on mozilla49) fixed it again.

We have plenty of stack dumps, for example here:
http://archive.mozilla.org/pub/thunderbird/tinderbox-builds/comm-beta-win32-debug/1466381546/comm-beta_xp_ix-debug_test-mozmill-bm109-tests1-windows-build2.txt.gz
Search for the string |contentPolicyType not supported yet|.

As was said earlier, it only crashes in debug mode on a MOZ_ASSERT here:
https://dxr.mozilla.org/mozilla-beta/source/dom/security/nsContentSecurityManager.cpp#142

A search for TYPE_IMAGE in the code base gives few results:
https://dxr.mozilla.org/comm-central/search?q=TYPE_IMAGE&redirect=false

So the only possibility in fixing this would be to uplift bug 1206961 to mozilla48, currently in beta, so that's not a likely thing to happen.

So, since the only crashes in debug mode, should we worry about this for our Thunderbird 48 beta? And should Firefox worry about it for their FF 48 beta?

(Putting NI again since I don't know how close you follow the bug).

Comment 11

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #10)
> We have plenty of stack dumps, for example here:
> http://archive.mozilla.org/pub/thunderbird/tinderbox-builds/comm-beta-win32-
> debug/1466381546/comm-beta_xp_ix-debug_test-mozmill-bm109-tests1-windows-
> build2.txt.gz
> Search for the string |contentPolicyType not supported yet|.

I was thinking about a 'real' stacktrace that let's me find out where the resource load originiated. Looking at the provided stacktrace it only gives me 2 levels before I get lost in the *.dll.

> As was said earlier, it only crashes in debug mode on a MOZ_ASSERT here:
> https://dxr.mozilla.org/mozilla-beta/source/dom/security/
> nsContentSecurityManager.cpp#142

Right, MOZ_ASSERTs disappear for release builds.

> So the only possibility in fixing this would be to uplift bug 1206961 to
> mozilla48, currently in beta, so that's not a likely thing to happen.

I think this is not going to happen.

> So, since the only crashes in debug mode, should we worry about this for our
> Thunderbird 48 beta? And should Firefox worry about it for their FF 48 beta?

Why exactly would it be a problem for Firefox?

Comment 12

[Jorg K (CEST = GMT+2)]

I'm not sure what I'm answering here. I basically know nothing about security and the internals you've changed.

The facts are: Bug 1257930 (landed on mozilla48) switched over NetUtil.jsm from asyncOpen() to asyncOpen2(). Somehow that caused a problem in one of the TB tests, I can't even tell which. But it seems to have to do with loading images (TYPE_IMAGE). Given that TB can be considered a FF add-on, I can't exclude the possibility that other add-ons or even FF core functionality is affected. I can't tell why "exactly" this would be a problem.

Sorry about the bad stack dump. This is now only happening on the beta branch, so I don't have a debug build of that.

Bug 1206961 cut over the image loader to asyncOpen2() and suddenly the problem went away again. So between the landing of the former bug and the latter bug there is some internal inconsistency which may or may not affect FF. I can even see a change/review comment that this "intermediate state" isn't ideal: attachment 8741442 [details] [diff] [review].

We have seen another bug where the cut-over to asyncOpen2() has lead to bugs in both FF and TB, bug 1269254.

If you think that FF 48 is not affected, fine. If, however, there is an obscure bug that some icon on some tab doesn't show, then this will come back to us ;-)

Comment 13

[Christoph Kerschbaumer [:ckerschb]]

(In reply to Jorg K (GMT+2, PTO during summer, NI me) from comment #12)
> The facts are: Bug 1257930 (landed on mozilla48) switched over NetUtil.jsm
> from asyncOpen() to asyncOpen2(). Somehow that caused a problem in one of
> the TB tests, I can't even tell which.

Can we figure out which test? I am confident that within Firefox we haven't used asyncOpen2() for any of the TYPE_IMAGE loads even after landing Bug 1257930. If the patch within that bug really caused a problem for TB, then some TB specific code must have used set a securityflag other than SEC_NORMAL for TYPE_IMAGE loads. That is the only possible scenario. If that is the case, we have to figure out where that code is. I assume it's easier to land a hotfix within TB code than Firefox code

Comment 14

[Jorg K (CEST = GMT+2)]

First of all, thanks for you continued help.

I'm reading logs for our Mozmill tests again:

Here is a non-debug run:

05:00:09     INFO -  TEST-START | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | setupModule
05:00:09     INFO -  TEST-PASS | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | test-lwthemes.js::setupModule
05:00:09     INFO -  TEST-START | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | test_lightweight_themes_install
05:00:09     INFO -  dispatching InstallBrowserTheme
05:00:09     INFO -  JavaScript error: chrome://global/content/bindings/notification.xml, line 463: TypeError: this.close is not a function
05:00:10     INFO -  1466251210165	addons.xpi	WARN	Attempting to activate an already active default theme
05:00:10     INFO -  dispatching InstallBrowserTheme
05:00:10     INFO -  2016-06-18 05:00:10.364 thunderbird[8282:424383] Persistent UI failed to open file file://localhost/Users/cltbld/Library/Saved%20Application%20State/org.mozilla.earlybird.savedState/window_1.data: No such file or directory (2)
05:00:10     INFO -  dispatching PreviewBrowserTheme
05:00:10     INFO -  JavaScript error: chrome://global/content/bindings/notification.xml, line 463: TypeError: this.close is not a function
05:00:10     INFO -  dispatching ResetBrowserThemePreview
05:00:18     INFO -  TEST-PASS | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | test-lwthemes.js::test_lightweight_themes_install
05:00:18     INFO -  TEST-START | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | test_lightweight_themes_install_and_undo
05:00:18     INFO -  WARNING | test-lwthemes.js::test_lightweight_themes_install_and_undo | (SKIP) True
05:00:18     INFO -  TEST-START | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | teardownModule
05:00:18     INFO -  TEST-PASS | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | test-lwthemes.js::teardownModule

Note the:
dispatching InstallBrowserTheme
dispatching PreviewBrowserTheme
dispatching ResetBrowserThemePreview

So we have a test "test-lwthemes.js"
https://dxr.mozilla.org/comm-central/source/mail/test/mozmill/content-tabs/test-lwthemes.js#59
which spits out a few TypeErrors but in the end passes.

Here the debug version:

04:36:31     INFO -  TEST-START | /builds/slave/test/build/tests/mozmill/content-tabs/test-lwthemes.js | test_lightweight_themes_install
04:36:31     INFO -  ++DOCSHELL 0x11063d800 == 17 [pid = 1817] [id = 39]
04:36:31     INFO -  ++DOMWINDOW == 39 (0x115cd0800) [pid = 1817] [serial = 116] [outer = 0x0]
04:36:31     INFO -  ++DOMWINDOW == 40 (0x1161b0000) [pid = 1817] [serial = 117] [outer = 0x115cd0800]
04:36:32     INFO -  [1817] WARNING: NS_ENSURE_TRUE(aURI) failed: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/netwerk/cache2/OldWrappers.cpp, line 918
04:36:32     INFO -  ++DOMWINDOW == 41 (0x116319400) [pid = 1817] [serial = 118] [outer = 0x115cd0800]
04:36:32     INFO -  --DOCSHELL 0x115273000 == 16 [pid = 1817] [id = 38]
04:36:32     INFO -  --DOMWINDOW == 40 (0x112e09000) [pid = 1817] [serial = 112] [outer = 0x0] [url = about:blank]
04:36:32     INFO -  dispatching InstallBrowserTheme
04:36:32     INFO -  [1817] WARNING: We should have hit the document element...: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/layout/xul/BoxObject.cpp, line 175
04:36:33     INFO -  [1817] WARNING: We should have hit the document element...: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/layout/xul/BoxObject.cpp, line 175
04:36:33     INFO -  JavaScript error: chrome://global/content/bindings/notification.xml, line 463: TypeError: this.close is not a function
04:36:33     INFO -  [1817] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp, line 846
04:36:33     INFO -  1466249793884	addons.xpi	WARN	Attempting to activate an already active default theme
04:36:34     INFO -  [1817] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp, line 846
04:36:34     INFO -  --DOCSHELL 0x111fd1800 == 15 [pid = 1817] [id = 36]
04:36:34     INFO -  dispatching InstallBrowserTheme
04:36:34     INFO -  [1817] WARNING: We should have hit the document element...: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/layout/xul/BoxObject.cpp, line 175
04:36:34     INFO -  dispatching PreviewBrowserTheme
04:36:35     INFO -  [1817] WARNING: We should have hit the document element...: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/layout/xul/BoxObject.cpp, line 175
04:36:35     INFO -  JavaScript error: chrome://global/content/bindings/notification.xml, line 463: TypeError: this.close is not a function
04:36:35     INFO -  [1817] WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x80520012: file /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/js/xpconnect/loader/mozJSComponentLoader.cpp, line 846
04:36:35     INFO -  dispatching ResetBrowserThemePreview
04:36:35     INFO -  Assertion failure: false (contentPolicyType not supported yet), at /builds/slave/tb-c-beta-m64-d-00000000000000/build/mozilla/dom/security/nsContentSecurityManager.cpp:142

So basically this is a test switching themes. Most likely themes have images and those get loaded (or not) somehow.

There is really no Thunderbird code behind this at all that we could "hotfix".

Maybe if you ran a similar test on FF 48 or if you switched themes manually, something would not work or even crash in debug mode.

Comment 15

[Jorg K (CEST = GMT+2)]

This was last seen on C-B, see comment #3. After the branch date on Aug 1st, 2016, this is now gone.

Summarising: Caused by bug 1257930 (landed on mozilla48) and fixed by bug 1206961 (landed on mozilla49).