Last Comment Bug 657292 - Firefox 6.0a1 Crash Report [@ xpc::XrayWrapper<JSCrossCompartmentWrapper>::createHolder(JSContext*, JSObject*, JSObject*) ][@ xpc::XrayWrapper<JSCrossCompartmentWrapper>::createHolder ]
: Firefox 6.0a1 Crash Report [@ xpc::XrayWrapper<JSCrossCompartmentWrapper>::cr...
[firebug-p1] fixed-in-tracemonkey [tr...
: crash, regression
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: -- critical (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017)
: Jason Orendorff [:jorendorff]
: 660589 (view as bug list)
Depends on:
Blocks: 641342 657125
  Show dependency treegraph
Reported: 2011-05-16 01:08 PDT by Jan Honza Odvarko [:Honza]
Modified: 2013-12-27 14:23 PST (History)
25 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

Firebug test XPI (1.23 MB, application/x-xpinstall)
2011-05-16 01:13 PDT, Jan Honza Odvarko [:Honza]
no flags Details
Proposed fix (2.49 KB, patch)
2011-05-20 11:00 PDT, Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017)
gal: review+
dmandelin: approval‑mozilla‑aurora+
dmandelin: approval‑mozilla‑beta+
Details | Diff | Splinter Review

Description Jan Honza Odvarko [:Honza] 2011-05-16 01:08:17 PDT

Last working build:


1) Install Firebug (attached XPI)
2) Restart and open Firebug UI (F12)

Comment 1 Jan Honza Odvarko [:Honza] 2011-05-16 01:13:30 PDT
Created attachment 532576 [details]
Firebug test XPI
Comment 2 Jan Honza Odvarko [:Honza] 2011-05-16 03:10:53 PDT
Marking as Firebug-p1 since this is blocking Firebug team from testing on nightlies.

Comment 3 Jan Honza Odvarko [:Honza] 2011-05-16 03:14:16 PDT
Yet another way how to see the exact regression range:
(started crashing on Sat: 14 May 2011 01:19:01 GMT, App Changeset: c2bea9fde3b0)

Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-05-16 11:33:39 PDT
Regression range from comment 0:

Nothing in there jumps out at me....
Comment 5 jorge alves 2011-05-16 17:32:59 PDT
There's a tracemonkey merge in there...

Trying out hourly builds I got to this:
Comment 6 Robert Kaiser 2011-05-17 09:17:37 PDT
As of yesterday, this is the #1 crash on trunk with roughly 10% of all trunk crashes!
All the 6.0a1 crashes I checked in do have Firebug installed - but there are a few 4.0.1 crashes with the same signature (probably some other cause) and those don't have Firebug installed.

Still, the Nightly+Firebug problem is the immediate one, we should get that fixed, ideally before this code goes into Aurora next week.
Comment 7 Boris Zbarsky [:bz] (still a bit busy) 2011-05-17 09:45:54 PDT
jorge: can you try Tracemonkey nightlies and/or hourlies?
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2011-05-17 09:47:10 PDT
ccing some of the people in that range too.
Comment 9 Marcia Knous [:marcia - use ni] 2011-05-17 10:44:50 PDT
Happens on Mac as well, 
[@ xpc::XrayWrapper<JSCrossCompartmentWrapper>::createHolder ]
Comment 11 jorge alves 2011-05-17 13:38:58 PDT
BTW, is there an easier way to browse and test these builds?
Doing it manually is a bit error-prone.
Comment 12 Boris Zbarsky [:bz] (still a bit busy) 2011-05-17 13:48:21 PDT
jorge, might work.
Comment 13 Boris Zbarsky [:bz] (still a bit busy) 2011-05-17 13:53:21 PDT
Blake, this looks like a regression from bug 641342.

All the crashes are at 0x10, which looks like a null deref somewhere here.

This code:

    2.15 +        JSObject *inner = obj;
    2.16 +        OBJ_TO_INNER_OBJECT(cx, inner);
    2.17 +        XPCWrappedNative *wn;
    2.18 +        if (IS_WN_WRAPPER(inner) &&
    2.19 +            (wn = static_cast<XPCWrappedNative *>(inner->getPrivate()))->HasProto() &&
    2.20 +            wn->GetProto()->ClassIsDOMObject()) {
    2.21 +            typedef XrayWrapper<JSCrossCompartmentWrapper> Xray;
    2.22 +            wrapper = &FilteringWrapper<Xray,
    2.23 +                                        CrossOriginAccessiblePropertiesOnly>::singleton;
    2.24 +            xrayHolder = Xray::createHolder(cx, obj, parent);

looks to me like a gc hazard if |inner| can go away while |obj| stays around, since nothing is using |inner| in this case after we get |wn|.  Can inner go away that way?
Comment 14 Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017) 2011-05-20 11:00:31 PDT
Created attachment 534029 [details] [diff] [review]
Proposed fix

In practice inner and outer are related, so there's no GC hazard there. That being said, I cleaned up the code a little bit. The actual fix is checking targetdata before trying to create the Xray wrapper.

Do note that I haven't actually been able to reproduce the crash. But based on crash stacks, this has to be the fix.
Comment 15 jorge alves 2011-05-20 15:28:30 PDT
(In reply to comment #14)
Applying the patch to current mozilla-central fixes the problem on my end.

Latest nightly still crashes.
Comment 16 Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017) 2011-05-24 02:59:45 PDT
Comment 17 Jan Honza Odvarko [:Honza] 2011-05-26 05:10:16 PDT
Still crashes in the latest Nightly channel. This bug blocks me to test Firebug on Nightlies and so, I have no idea whether there are any other problems raising.

Comment 18 Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017) 2011-05-26 06:16:24 PDT
Comment 19 Robert Kaiser 2011-05-26 06:24:07 PDT
(In reply to comment #18)

Nice! If this works out, we'll want it on aurora as well, I guess, as this crash should be on Aurora 6 now.
Comment 22 Sebastian Zartner 2011-05-26 22:37:24 PDT
For me it is still not fixed yet. See
Or didn't your fix make it into the latest nightly yet?
Comment 23 Boris Zbarsky [:bz] (still a bit busy) 2011-05-26 22:48:21 PDT
Yep.  Blake's push was at 2011-05-26 06:15 Pacific, while that crash report is from a nightly that was pulled at 2011-05-26 03:05 Pacific.
Comment 24 Sebastian Zartner 2011-05-27 15:20:30 PDT
Thanks, now the nightlies are finally working again. Though it seems the error now leaked into Aurora:
So hopefully there'll be an update soon.
Comment 25 Robert Kaiser 2011-05-27 16:25:06 PDT
(In reply to comment #24)
> Though it seems the
> error now leaked into Aurora

That's why approval‑mozilla‑aurora had been requested and now granted, the latter meaning that the fix will soon be pushed there (a comment here will be made about this) and then fixed Aurora builds will appear.
Comment 26 Arie Paap [:wildmyron] 2011-05-30 00:45:30 PDT
*** Bug 660589 has been marked as a duplicate of this bug. ***
Comment 27 Robert Kaiser 2011-05-31 09:26:23 PDT
Blake, can you please land this on Aurora? The last builds on trunk that are seeing this crash are the nightlies from before you checked in on m-c, but Aurora is still hitting this significantly. This crash now takes the two top spots in 6.0a2 topcrashes...
Comment 29 Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017) 2011-05-31 10:20:17 PDT
Comment 30 Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017) 2011-06-06 11:14:23 PDT
Comment 31 George Carstoiu 2011-06-09 06:52:35 PDT
Verified on Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0 - 5b5 and also on Mac OS X 10.6, Ubuntu 10.10 x86 and Win7 using the steps from Description.

Issue no longer present - setting status to Verified Fixed.

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