656171 - Assertion failure: callerPrincipals->subsume(callerPrincipals, calleePrincipals), at js/src/jsobj.cpp:1346

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Mats Palmgren (inactive)]

Attachment: stack with some data

Assertion failure: callerPrincipals->subsume(callerPrincipals, calleePrincipals), at js/src/jsobj.cpp:1346


Up-to-date Linux x86-64 debug build; aborts shortly after start.
It's 100% reproducible (also after rebuild with empty $OBJDIR).
See attached stack for some data on the principals involved in the assert.

# hg ident
618cad1b1743 tip

Comment 1

[David Mandelin [:dmandelin]]

Do you have a test case?

Comment 2

[Bob Clary [:bc] (inactive)]

I see this on 32|64bit Linux and 32bit Mac as well. Windows builds pending.

Comment 3

[Mats Palmgren (inactive)]

Using a clean profile, load http://english.aljazeera.net/watch_now/

Comment 4

[David Mandelin [:dmandelin]]

I get it too. How about a regression range?

Comment 5

[Luke Wagner [:luke]]

This is an extension of the issue in bug 651298.  It is probably just be a matter of relaxing the assert or using the slower object principal finder instead of relying on the compartment's principals.  The underlying issue is that we cheat to make document.domain work and break what would otherwise be reasonable invariants.  Like practically everything these days, bug 650353 would allow this assert to hold, hence whatever we do in the interim is temporary.

Comment 6

[Bob Clary [:bc] (inactive)]

definitely windows as well. Another url:

http://www.msnbc.msn.com/id/42953750/ns/us_news-life/t/doc-woman-stranded-weeks-was-close-dying/?GT1=43001

plus 104 others so far.

Comment 7

[Luke Wagner [:luke]]

Attachment: use object principals finder instead of compartment->principals

mrbkap and I looked at one of these under gdb and it is the document.domain trickery.  Same fix as before.

Comment 8

[Luke Wagner [:luke]]

http://hg.mozilla.org/tracemonkey/rev/5f2b3783cdd6

Comment 9

[Bob Clary [:bc] (inactive)]

how often do we get mc<->tracemonkey merges? once a week? any chance of getting this onto mc sooner?

Comment 10

[Luke Wagner [:luke]]

Can do; I'll land it on mc as soon as it goes green on tm.

Comment 11

[Luke Wagner [:luke]]

... and its a good thing I did.  xpcshell is doing some weird things with its fake principals manager.  Will look at this tomorrow.

Backed out:
http://hg.mozilla.org/tracemonkey/rev/5b479a987cda

Comment 12

[Luke Wagner [:luke]]

Relanded and stuck:
http://hg.mozilla.org/tracemonkey/rev/16b4d6aa5b2b

Comment 13

[Luke Wagner [:luke]]

http://hg.mozilla.org/mozilla-central/rev/16b4d6aa5b2b

Comment 14

[Bob Clary [:bc] (inactive)]

I'm in the middle of retesting the urls where I saw this assertion. It appears that it still occurs at http://www.sfr.fr/mobile/telephone-portable/apple-iphone-4-16go-noir?vue=000029 on WinXP on a nightly build from 5/19. File a new bug?

Comment 15

[Luke Wagner [:luke]]

#3  in js::PrincipalsForCompiledCode at jsobj.cpp:1346
(gdb) p calleePrincipals->codebase
$1 = "http://www.sfr.fr/mobile/telephone-portable/apple-iphone-4-16go-noir?vue=000029"
(gdb) p callerPrincipals->codebase
$2 = "http://www.sfr.fr/mobile/edito/tcommerce/inqChat.html?IFRAME"

Blake: can we just drop this assertion?  Seems to be more of this document.domain-hack-leakage that I thought you explained was technically ok.

Comment 16

[Blake Kaplan (:mrbkap) (inactive)]

Yeah, I guess so... Do we have compartment-per-global yet?

Comment 17

[Luke Wagner [:luke]]

(In reply to comment #16)
> Yeah, I guess so... Do we have compartment-per-global yet?

I'll go poke bent.

Comment 18

[Luke Wagner [:luke]]

Attachment: kill the assert

Comment 19

[Luke Wagner [:luke]]

http://hg.mozilla.org/tracemonkey/rev/c8e12e8c281b