606390 - compartment mismatch assertion loading article on sfgate.com

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: gdb log

I was reading the news and hit a compartment mismatched assertion; jst helped drive gdb, and thinks we *might* have enough information to fix something.

gdb log is attached.  It's a little messy because of crashes during things we called from gdb that changed all the stack frame numbers.  Also, it's a debug+optimized build, so some things were missing, but we were able to work around those things being missing by getting the data out of other stack frames.

The highlights are:

 * the assertion is failing because it's a mismatch on the return value of nsIDOMHTMLDocument_GetBody (generated code in dom_quickstubs.cpp).  jst suspects the line:
        *vp = OBJECT_TO_JSVAL(wrapper);
inside the if (cache) branch.

 * the expected compartment had principals for
   http://onespot.sfgate.com/static/nextclick/gam.html but the result of GetBody (the js::Value being checked in assertSameCompartment<JSObject*, js::Value>) had a compartment with principals for http://www.sfgate.com/chronicle/


The top of the C++ stack was:

#6  0x00007f18938388ef in assertSameCompartment<JSObject*, js::Value> (
    this=<value optimized out>, cx=0x7f183b89c350, proxy=0x7f182d625198, 
    receiver=<value optimized out>, id=..., vp=0x7fffcd4253e0)
    at /home/dbaron/builds/mozilla-central/mozilla/js/src/jscntxtinlines.h:602
#7  CallJSPropertyOp (this=<value optimized out>, cx=0x7f183b89c350, 
    proxy=0x7f182d625198, receiver=<value optimized out>, id=..., 
    vp=0x7fffcd4253e0)
    at /home/dbaron/builds/mozilla-central/mozilla/js/src/jscntxtinlines.h:698
#8  js::JSProxyHandler::get (this=<value optimized out>, cx=0x7f183b89c350, 
    proxy=0x7f182d625198, receiver=<value optimized out>, id=..., 
    vp=0x7fffcd4253e0)
    at /home/dbaron/builds/mozilla-central/mozilla/js/src/jsproxy.cpp:139
#9  0x00007f189383307f in js::JSProxy::get (cx=0x7f183b89c350, 
    proxy=0x7f182d625198, receiver=0x7f182d625198, id=..., vp=0x7fffcd4253e0)
    at /home/dbaron/builds/mozilla-central/mozilla/js/src/jsproxy.cpp:774
#10 0x00007f1893833102 in proxy_GetProperty (cx=0x38fa, obj=0x38fa, 
    id=<value optimized out>, vp=0x7f1894f11800)
    at /home/dbaron/builds/mozilla-central/mozilla/js/src/jsproxy.cpp:867

My source tree was based on http://hg.mozilla.org/mozilla-central/rev/11ab1b90ee17
plus the patches in http://hg.mozilla.org/users/dbaron_mozilla.com/patches/rev/8d6d4faad492

Comment 1

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

A little more information:

(gdb) up
#15 0x00007f189383307f in js::JSProxy::get (cx=0x7f183b89c350, 
    proxy=0x7f182d625198, receiver=0x7f182d625198, id=..., vp=0x7fffcd4253e0)
    at /home/dbaron/builds/mozilla-central/mozilla/js/src/jsproxy.cpp:774
774	    return proxy->getProxyHandler()->get(cx, proxy, receiver, id, vp);
(gdb) p proxy
$19 = (JSObject *) 0x7f182d625198
(gdb) set print static-members off
(gdb) set print pretty on
(gdb) p *proxy->getProxyHandler()
$22 = (xpc::FilteringWrapper<xpc::XrayWrapper<JSCrossCompartmentWrapper, xpc::CrossCompartmentXray>, xpc::CrossOriginAccessiblePropertiesOnly>) {
  <xpc::XrayWrapper<JSCrossCompartmentWrapper, xpc::CrossCompartmentXray>> = {
    <JSCrossCompartmentWrapper> = {
      <JSWrapper> = {
        <js::JSProxyHandler> = {
          _vptr.JSProxyHandler = 0x7f1894471550, 
          mFamily = 0x7f1894cc0648
        }, 
        members of JSWrapper: 
        mFlags = 14
      }, 
    }, 
  }, 
}

Comment 2

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: gdb log showing the docshell tree

This shows we're in an iframe:
http://onespot.sfgate.com/static/nextclick/gam.html?sfgate-pubmatic-test
inside of:
wyciwyg://55/http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2010/10/21/international/i034547D45.DTL&tsp=1
inside of:
http://www.sfgate.com/cgi-bin/article.cgi?f=/n/a/2010/10/21/international/i034547D45.DTL&tsp=1
inside of:
chrome://browser/content/browser.xul

Comment 3

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: tail of Firefox stdout, showing assertion (!domain) with stack

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Attachment: patch from Andreas and jst

Comment 5

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

http://hg.mozilla.org/mozilla-central/rev/bafbdc85d57b

Comment 6

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

So, after starting up the browser with the patch, I got a compartment mismatch at the exact same place, with the same getter (nsIDOMHTMLDocument_GetBody).  Investigating further now...

Comment 7

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

Er, never mind, not running the build I thought I was, due to a failed rsync.

Comment 8

[Andreas Gal :gal]

Could someone land this on TM as well?