Closed Bug 606390 Opened 11 years ago Closed 11 years ago

compartment mismatch assertion loading article on sfgate.com

Categories

(Core :: XPConnect, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- beta7+

People

(Reporter: dbaron, Assigned: gal)

Details

Attachments

(4 files)

Attached file 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
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
      }, 
    }, 
  }, 
}
Attachment #485219 - Flags: review+
blocking2.0: --- → beta7+
http://hg.mozilla.org/mozilla-central/rev/bafbdc85d57b
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
Assignee: nobody → gal
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...
Er, never mind, not running the build I thought I was, due to a failed rsync.
Could someone land this on TM as well?
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.