Last Comment Bug 651298 - Assertion failure: hookPrincipals == compPrincipals ... at jsobjinlines.h:877
: Assertion failure: hookPrincipals == compPrincipals ... at jsobjinlines.h:877
: dogfood
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Other Branch
: x86_64 Linux
-- normal (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: 602994
  Show dependency treegraph
Reported: 2011-04-19 16:45 PDT by Igor Bukanov
Modified: 2011-05-10 17:24 PDT (History)
6 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

stack trace (20.48 KB, text/plain)
2011-04-19 16:46 PDT, Igor Bukanov
no flags Details
Proposed fix (1.40 KB, patch)
2011-04-28 15:41 PDT, Blake Kaplan (:mrbkap)
luke: review+
Details | Diff | Splinter Review

Description User image Igor Bukanov 2011-04-19 16:45:25 PDT
I got the following assert when reading an articles on I could not reproduce it at will, but i managed to get it 3 times.

Assertion failure: hookPrincipals == compPrincipals || (hookPrincipals->subsume(hookPrincipals, compPrincipals) && compPrincipals->subsume(compPrincipals, hookPrincipals)), at /scratch/igor/m/tm/j/src/jsobjinlines.h:877
Comment 1 User image Igor Bukanov 2011-04-19 16:46:30 PDT
Created attachment 527152 [details]
stack trace
Comment 2 User image Igor Bukanov 2011-04-19 16:48:38 PDT
This happens when I browsed using a VNC session on a server. I guess I can keep the debugger running for some time there.
Comment 3 User image Igor Bukanov 2011-04-19 17:10:45 PDT
To Luke: can it be a fallout from bug 602994?
Comment 4 User image Luke Wagner [:luke] 2011-04-19 17:33:29 PDT
Well, that assert was definitely added by bug 602994.  But its a property that should generally be true: the compartment containing an object should have equivalent principals to those found through findObjectPrincipals.  What are the two principals involved?
Comment 5 User image Igor Bukanov 2011-04-19 22:27:22 PDT

Comment 6 User image Luke Wagner [:luke] 2011-04-19 22:53:17 PDT
Well good to see this isn't some terrible chrome privilege leaking.  Igor: Blake was suspecting document.domain at play; do you see any evidence of this?
Comment 7 User image Igor Bukanov 2011-04-19 23:10:23 PDT
(In reply to comment #6)
> Igor:
> Blake was suspecting document.domain at play; do you see any evidence of this?

document.domain is set to on but not on articles like
Comment 8 User image Igor Bukanov 2011-04-25 13:31:57 PDT
I got the same assert when browsing at (a Russian news site). It contains document.domain = ''.
Comment 9 User image Luke Wagner [:luke] 2011-04-25 14:42:56 PDT
Oh right, I talked to mrbkap about this IRL but then we got interrupted and the consensus was never recorded.

Blake explained that this is a problem where, even if two documents have the same domain, if only one of them sets document.domain, they get different (non-equivalent) principals.  Due to the lack of compartments==globals (bug 650353), this can lead to objects in the same compartment but with non-equivalent principals.  Blake explains this isn't a security hole because they must have started with the same principals, at which point, any evil actions could have happened.  Thus, the resolution was to delete the assert since there isn't anything weaker we could assert.  Furthermore, after bug 650353, the assert also wouldn't have much meaning since, IIUC, it would essentially be true by definition.
Comment 10 User image Blake Kaplan (:mrbkap) 2011-04-28 15:41:00 PDT
Created attachment 528974 [details] [diff] [review]
Proposed fix
Comment 11 User image Luke Wagner [:luke] 2011-04-28 17:18:01 PDT
But I thought you convinced me that the compartment's principals were good enough?  Or have you convinced yourself otherwise now?
Comment 12 User image Luke Wagner [:luke] 2011-04-28 17:33:41 PDT
Comment on attachment 528974 [details] [diff] [review]
Proposed fix

IRL answer from mrbkap: 'yes'
Comment 13 User image David Baron :dbaron: ⌚️UTC-8 2011-04-29 08:20:17 PDT
So I see this assertion reliably while restoring a session.  In particular, I'm asserting on a script in:
while loading:
in a tab.

When I apply the fix (attachment 528974 [details] [diff] [review]), however, I still hit a fatal assertion... just a different one:

Assertion failure: callerPrincipals->subsume(callerPrincipals, calleePrincipals), at /home/dbaron/builds/ssd/mozilla-central/mozilla/js/src/jsobj.cpp:1344

In this case, in js::PrincipalsForCompiledCode, calleePrincipals->codebase
is ""
but unfortunately callerPrincipals is <value optimized out>.

Is that a continuation of this bug, or another one?
Comment 14 User image Bob Clary [:bc:] 2011-05-02 03:47:36 PDT
I've seen Assertion failure: hookPrincipals == compPrincipals  on a number of urls on Windows, Mac and 32bit as well as 64 bit Linux. It is quite common and will negatively impact crash testing the trunk. It would be very very nice if this landed soon.
Comment 16 User image Blake Kaplan (:mrbkap) 2011-05-05 15:16:41 PDT

We should open a second bug for the other compartment mismatch.
Comment 17 User image Chris Leary [:cdleary] (not checking bugmail) 2011-05-10 15:12:29 PDT
cdleary-bot mozilla-central merge info:
Comment 18 User image Luke Wagner [:luke] 2011-05-10 17:24:25 PDT
It looks like the follow-up was just filed with bug 656171.

Note You need to log in before you can comment on or make changes to this bug.