Closed Bug 605290 Opened 15 years ago Closed 14 years ago

Crash in [@ JSCompartment::wrap(JSContext*, js::Value*) ] [@ JSCompartment::wrap] mainly with Firebug (Mac) or Adblock Plus (Windows) or Video Download Helper (both)

Categories

(Core :: JavaScript Engine, defect)

Product:
Core
Component:
JavaScript Engine
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla8
Tracking Flags:
Tracking Status
firefox7 --- affected

People

(Reporter: marcia, Assigned: dmandelin)

References

Details

(Keywords: crash, regression, topcrash, Whiteboard: [compartments][softblocker][tbird crash])

Crash Data

Attachments

(1 file, 2 obsolete files)

Patch v3
3.98 KB, patch
luke
: review+
Details | Diff | Splinter Review
Seen while reviewing chofmann's daily crash report. http://tinyurl.com/3xjjzn7 to the crashes which are all Windows. Crashes started showing up in crash stats using the 2010101300 build. Frame Module Signature [Expand] Source 0 mozjs.dll JSCompartment::wrap js/src/jscompartment.cpp:147 1 mozjs.dll JSCrossCompartmentWrapper::call js/src/jswrapper.cpp:594 2 mozjs.dll js::JSProxy::call js/src/jsproxy.cpp:802 3 mozjs.dll js::proxy_Call js/src/jsproxy.cpp:1027 4 mozjs.dll js::Invoke js/src/jsinterp.cpp:674 5 mozjs.dll js::ExternalInvoke js/src/jsinterp.cpp:871 6 mozjs.dll js::ExternalGetOrSet js/src/jsinterp.cpp:891 7 mozjs.dll js::JSProxyHandler::get js/src/jsproxy.cpp:131 8 mozjs.dll js::JSProxy::get js/src/jsproxy.cpp:774 9 mozjs.dll js::proxy_GetProperty js/src/jsproxy.cpp:867 10 mozjs.dll JSObject::getProperty js/src/jsobj.h:1047 11 mozjs.dll js::Interpret js/src/jsinterp.cpp:4115 12 mozjs.dll js::RunScript js/src/jsinterp.cpp:638 13 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 14 mozjs.dll js_fun_apply js/src/jsfun.cpp:2369 15 mozjs.dll js::Interpret js/src/jsinterp.cpp:4714 16 mozjs.dll js::RunScript js/src/jsinterp.cpp:638 17 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 18 mozjs.dll js_fun_apply js/src/jsfun.cpp:2369 19 mozjs.dll js::Interpret js/src/jsinterp.cpp:4714 20 mozjs.dll js::RunScript js/src/jsinterp.cpp:638 21 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 22 mozjs.dll js_fun_apply js/src/jsfun.cpp:2369 23 mozjs.dll js::Interpret js/src/jsinterp.cpp:4714 24 mozjs.dll js::RunScript js/src/jsinterp.cpp:638 25 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 26 mozjs.dll js::InvokeSessionGuard::invoke js/src/jsinterpinlines.h:553 27 mozjs.dll array_extra js/src/jsarray.cpp:2721 28 mozjs.dll array_forEach js/src/jsarray.cpp:2778 29 mozjs.dll js::Interpret js/src/jsinterp.cpp:4714 30 mozjs.dll js::RunScript js/src/jsinterp.cpp:638 31 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 32 mozjs.dll js_fun_apply js/src/jsfun.cpp:2369 33 mozjs.dll js::Interpret js/src/jsinterp.cpp:4714 34 mozjs.dll js::RunScript js/src/jsinterp.cpp:638 35 mozjs.dll js::Invoke js/src/jsinterp.cpp:747 36 mozjs.dll js::ExternalInvoke js/src/jsinterp.cpp:871 37 mozjs.dll JS_CallFunctionValue js/src/jsapi.cpp:4961 38 xul.dll nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1692 39 xul.dll nsXPCWrappedJS::CallMethod js/src/xpconnect/src/xpcwrappedjs.cpp:571 40 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:114 41 xul.dll SharedStub xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp:141 42 xul.dll nsBrowserStatusFilter::OnLocationChange toolkit/components/statusfilter/nsBrowserStatusFilter.cpp:231 43 xul.dll nsDocLoader::FireOnLocationChange uriloader/base/nsDocLoader.cpp:1377 44 xul.dll nsDocShell::CreateContentViewer docshell/base/nsDocShell.cpp:7403 45 xul.dll nsDSURIContentListener::DoContent docshell/base/nsDSURIContentListener.cpp:138 46 xul.dll nsDocumentOpenInfo::TryContentListener uriloader/base/nsURILoader.cpp:757 47 xul.dll nsDocumentOpenInfo::DispatchContent uriloader/base/nsURILoader.cpp:455 48 xul.dll nsDocumentOpenInfo::OnStartRequest uriloader/base/nsURILoader.cpp:295 49 xul.dll nsHttpChannel::CallOnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:770 50 xul.dll nsHttpChannel::ContinueProcessNormal netwerk/protocol/http/nsHttpChannel.cpp:1228 51 mozcrt19.dll arena_dalloc_small obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4204 52 mozcrt19.dll arena_dalloc obj-firefox/memory/jemalloc/crtsrc/jemalloc.c:4281 53 xul.dll nsHttpChannel::ProcessNormal netwerk/protocol/http/nsHttpChannel.cpp:1165 54 xul.dll nsHttpChannel::ProcessResponse netwerk/protocol/http/nsHttpChannel.cpp:1052 55 xul.dll nsHttpChannel::OnStartRequest netwerk/protocol/http/nsHttpChannel.cpp:3805 56 xul.dll nsInputStreamPump::OnStateStart netwerk/base/src/nsInputStreamPump.cpp:441 57 xul.dll nsInputStreamPump::OnInputStreamReady netwerk/base/src/nsInputStreamPump.cpp:397 58 xul.dll nsInputStreamReadyEvent::Run xpcom/io/nsStreamUtils.cpp:112 59 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:547 60 xul.dll mozilla::ipc::MessagePump::Run ipc/glue/MessagePump.cpp:110 61 xul.dll xul.dll@0xae48cb 62 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:202 63 mozsqlite3.dll sqlite3Pragma 64 nspr4.dll PR_IsNetAddrType nsprpub/pr/src/misc/prnetdb.c:1533 65 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:176 66 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:180 67 xul.dll xul.dll@0xae48cb 68 xul.dll nsAppShell::Run widget/src/windows/nsAppShell.cpp:243 69 nss3.dll pkix_pl_CertNameConstraints_ToString security/nss/lib/libpkix/pkix_pl_nss/pki/pkix_pl_nameconstraints.c:539
looks like this might have first appeared on the trunk on sept 14 in builds from the 13th. slow uptick in volume after that. date tl crashes at, count build, count build, ... JSCompartment::wrap.JSContext...js::Value.. 20101013 20101014 3 2 4.0b8pre2010101404, 1 4.0b8pre2010101322, 20101015 5 4 4.0b8pre2010101504, 1 4.0b8pre2010101404, 20101016 6 3 4.0b8pre2010101604, 3 4.0b8pre2010101504, 20101017 9 6 4.0b8pre2010101604, 2 4.0b8pre2010101704, 1 4.0b8pre2010101504,
Keywords: regression
Blocking 2.0 beta 8 to make sure we investigate this.
blocking2.0: ? → beta8+
OS: Windows XP → All
Summary: Crash in [@ JSCompartment::wrap(JSContext*, js::Value*) ] → Crash in [@ JSCompartment::wrap(JSContext*, js::Value*) ] [@ JSCompartment::wrap ]
This one's been dropping the past few days. It is probably fallout from various compartment/thread faults that are being fixed.
I encountered this yesterday, with the Oct 30th nightly build. It occurred when I clicked another tab while a cbsnews.com video was playing; however, I'm unable to find a way to reproduce. http://crash-stats.mozilla.com/report/index/bp-2b8c48fa-1879-4d31-a391-0fc9a2101030
Whiteboard: [compartments]
blocking2.0: beta8+ → beta9+
Somewhat similar-looking crash on tinderbox: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1290133792.1290136166.20784.gz WINNT 5.2 mozilla-central debug test mochitest-other on 2010/11/18 18:29:52 s: mw32-ix-slave05 PROCESS-CRASH | Main app process exited normally | application crashed (minidump found) Thread 0 (crashed) TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/xpinstall/browser_badargs.js | Exited with code -1073741819 during test run PROCESS-CRASH | chrome://mochitests/content/browser/toolkit/mozapps/extensions/test/xpinstall/browser_badargs.js | application crashed (minidump found) Thread 0 (crashed) TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | missing output line for total leaks! Crash reason: EXCEPTION_ACCESS_VIOLATION_READ Crash address: 0xffffffffdadadb26 Thread 0 (crashed) 0 mozjs.dll!JSCompartment::wrap(JSContext *,js::Value *) [jscompartment.cpp:302e3ea21728 : 165 + 0x8] eip = 0x00697210 esp = 0x0012b874 ebp = 0x0012b8b4 ebx = 0x00000001 esi = 0x089d1f74 edi = 0xffff0007 eax = 0xdadadada ecx = 0x05ef14c8 edx = 0x05ef1000 efl = 0x00010282 Found by: given as instruction pointer in context 1 mozjs.dll!JSCompartment::wrap(JSContext *,JSObject * *) [jscompartment.cpp:302e3ea21728 : 265 + 0x14] eip = 0x006978ed esp = 0x0012b8bc ebp = 0x0012b8fc Found by: previous frame's frame pointer 2 mozjs.dll!JS_WrapObject [jsapi.cpp:302e3ea21728 : 1209 + 0x12] eip = 0x005f0127 esp = 0x0012b904 ebp = 0x0012b914 Found by: previous frame's frame pointer 3 xul.dll!XPCConvert::NativeInterface2JSObject(XPCLazyCallContext &,jsval_layout *,nsIXPConnectJSObjectHolder * *,xpcObjectHelper &,nsID const *,XPCNativeInterface * *,JSObject *,int,int,unsigned int *) [xpcconvert.cpp:302e3ea21728 : 1199 + 0x12] eip = 0x11162b66 esp = 0x0012b91c ebp = 0x0012ba18 Found by: call frame info 4 xul.dll!XPCConvert::NativeData2JS(XPCLazyCallContext &,jsval_layout *,void const *,nsXPTType const &,nsID const *,JSObject *,unsigned int *) [xpcconvert.cpp:302e3ea21728 : 491 + 0x27] eip = 0x11160d55 esp = 0x0012ba20 ebp = 0x0012bbac Found by: call frame info 5 xul.dll!XPCConvert::NativeData2JS(XPCCallContext &,jsval_layout *,void const *,nsXPTType const &,nsID const *,JSObject *,unsigned int *) [xpcprivate.h:302e3ea21728 : 3231 + 0x23] eip = 0x11164e06 esp = 0x0012bbb4 ebp = 0x0012bc94 Found by: call frame info 6 xul.dll!CallMethodHelper::GatherAndConvertResults() [xpcwrappednative.cpp:302e3ea21728 : 2562 + 0x2f] eip = 0x11170ae4 esp = 0x0012bc9c ebp = 0x0012be10 Found by: call frame info 7 xul.dll!CallMethodHelper::Call() [xpcwrappednative.cpp:302e3ea21728 : 2319 + 0x7] eip = 0x1117020c esp = 0x0012be18 ebp = 0x0012be24 Found by: call frame info 8 xul.dll!XPCWrappedNative::CallMethod(XPCCallContext &,XPCWrappedNative::CallMode) [xpcwrappednative.cpp:302e3ea21728 : 2268 + 0x15] eip = 0x1116ff3d esp = 0x0012be2c ebp = 0x0012bfa8 Found by: call frame info 9 xul.dll!XPC_WN_CallMethod(JSContext *,unsigned int,jsval_layout *) [xpcwrappednativejsops.cpp:302e3ea21728 : 1594 + 0xd] eip = 0x11154d8c esp = 0x0012bfb0 ebp = 0x0012c07c Found by: call frame info 10 mozjs.dll!js::CallJSNative(JSContext *,int (*)(JSContext *,unsigned int,js::Value *),unsigned int,js::Value *) [jscntxtinlines.h:302e3ea21728 : 684 + 0xe] eip = 0x0069bb04 esp = 0x0012c084 ebp = 0x0012c0a0 Found by: call frame info 11 mozjs.dll!js::Interpret(JSContext *,JSStackFrame *,unsigned int,JSInterpMode) [jsinterp.cpp:302e3ea21728 : 4743 + 0x20] eip = 0x006ad2ac esp = 0x0012c0a8 ebp = 0x0012d10c Found by: call frame info 12 mozjs.dll!js::RunScript(JSContext *,JSScript *,JSStackFrame *) [jsinterp.cpp:302e3ea21728 : 657 + 0x10] eip = 0x0069b20c esp = 0x0012d114 ebp = 0x0012d134 ebx = 0x00000001 Found by: call frame info 13 mozjs.dll!js::Invoke(JSContext *,js::CallArgs const &,unsigned int) [jsinterp.cpp:302e3ea21728 : 737 + 0x10] eip = 0x0069b677 esp = 0x0012d13c ebp = 0x0012d194 Found by: call frame info 14 mozjs.dll!js::ExternalInvoke(JSContext *,js::Value const &,js::Value const &,unsigned int,js::Value *,js::Value *) [jsinterp.cpp:302e3ea21728 : 858 + 0xe] eip = 0x0069c683 esp = 0x0012d19c ebp = 0x0012d1d4 Found by: call frame info 15 mozjs.dll!js::ExternalInvoke [jsinterp.h:302e3ea21728 : 954 + 0x29] eip = 0x00600490 esp = 0x0012d1dc ebp = 0x0012d1fc Found by: call frame info 16 mozjs.dll!JS_CallFunctionValue [jsapi.cpp:302e3ea21728 : 4973 + 0x37] eip = 0x006008e4 esp = 0x0012d204 ebp = 0x0012d230 Found by: call frame info 17 xul.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS *,unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *) [xpcwrappedjsclass.cpp:302e3ea21728 : 1694 + 0x37] eip = 0x112254bb esp = 0x0012d238 ebp = 0x0012d69c Found by: call frame info 18 xul.dll!nsXPCWrappedJS::CallMethod(unsigned short,XPTMethodDescriptor const *,nsXPTCMiniVariant *) [xpcwrappedjs.cpp:302e3ea21728 : 588 + 0x29] eip = 0x1121fc93 esp = 0x0012d6a4 ebp = 0x0012d6dc Found by: call frame info 19 xul.dll!PrepareAndDispatch [xptcstubs.cpp:302e3ea21728 : 114 + 0x20] eip = 0x114f6bc6 esp = 0x0012d6e4 ebp = 0x0012d7b0 Found by: call frame info 20 xul.dll!SharedStub [xptcstubs.cpp:302e3ea21728 : 141 + 0x4] eip = 0x114f6896 esp = 0x0012d7b8 ebp = 0x0012d7cc Found by: call frame info 21 xul.dll!NS_InvokeByIndex_P [xptcinvoke.cpp:302e3ea21728 : 102 + 0x2] eip = 0x114f6697 esp = 0x0012d7d4 ebp = 0x0012d7cc Found by: call frame info with scanning
It is #25 top crasher in 4.0b8pre for the last week.
about 20-30 crashes per day now on beta7 and b8pre JSCompartment::wrap date total breakdown by build crashes count build, count build, ... 20101130 29 22 4.0b72010110413, 3 4.0b8pre2010113003, 3 4.0b72010110412, 1 4.0b8pre2010112803, Mardak may have isolated part of the problem in Bug 618118
Assignee: general → xpconnect
Assignee: xpconnect → nobody
Component: JavaScript Engine → XPConnect
QA Contact: general → xpconnect
Assignee: nobody → xpconnect
Component: XPConnect → JavaScript Engine
QA Contact: xpconnect → general
I can reproduce something like this problem by going to http://old.thesixtyone.com/ with the web inspector open.
Whiteboard: [compartments] → [compartments][hardblocker]
As per today's meeting, beta 9 will be a time-based release. Marking these all betaN+. Please move it back to beta9+ if you believe it MUST be in the next beta (ie: trunk is in an unshippable state without this)
blocking2.0: beta9+ → betaN+
Assignee: xpconnect → dmandelin
volume reduced on this in beta 8 down in ranking to #74 v. #18 in beta7 for JSCompartment::wrap(JSContext*, js::Value*)
This appears to be at least 3 separate bugs: one where the crash address is 0, another where is is 4, and at least one more with other addresses. 0 is the most common address. For that one, the problem is that XPCWrappedNative::CallMethod is trying to wrap an object jsval where the payload is 0 (i.e., an invalid jsval). We'd need to trace back further where that bad value is coming from in order to figure out more. Given that the volume is not too high, especially of each of the 3 sub-bugs, I'm going to put a lower priority on this, but it would still be nice to figure out more if possible.
Whiteboard: [compartments][hardblocker] → [compartments][softblocker]
Depends on: 623441
The null-tagged-as-object case could be caused by code not testing OOM and using the internal setObject/ObjectValue API (which does not dynamically test for null). Bug 623441 found such case in JSCompartment::wrap so we should see what happens to these crashes when that lands.
blocking2.0: betaN+ → .x
Bug 623441 didn't seem to be the cause.
Depends on: 626936
Depends on: 627227
My wife sees this crash several times a day on windows on beta 10. Is there anything I can do to provide more information to help this bug along?
If she's on Windows, then https://developer.mozilla.org/Capturing_a_minidump would be very very helpful.
Asa: could you test whether she experiences the same crash on a nightly? The reason I ask is that bug 627227 should fix a set of these crashes (what percent, I don't know) and it missed b10 but is in nightlies.
Luke, will do.
Depends on: 635298
bp-74b6004c-a0cc-452c-afc7-6217c2110318 0x4 using FF 4.0rc1 on vista is my first occurrence of this crash afaik. Interesting that the crash calls out http://platform0.twitter.com/widgets/tweet_button.html?_=1300478420908&count=horizontal&lang=en&text=Logitech%20Wireless%20Keyboard%20%7C%20eHow.com&url=http%3A%2F%2Fwww.ehow.com%2Flogitech-wireless-keyboard%2F&via=ehow ... I never accessed such a link, so it must be something from behind a google search or from an ehow page (where I did in fact search on logitech wireless keyboard) which I had not touched since restarting firefox and doing session restore. I crash OOM once or twice a week, so comment 14 may be relevant to my crash. OTOH, there are comments on crash-stats like * 4.0 Pre-release after 8 hrs running. 17? open Tabs. (which isn't much) * wasn't doing anything. Came home and Firefox had crashed... 2/3 of 4.0 crashes from the past week are 0x4 https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A4.0&query_search=signature&query_type=exact&query=JSCompartment%3A%3Awrap%28JSContext*%2C%20js%3A%3AValue*%29&date=03%2F18%2F2011%2015%3A04%3A25&range_value=1&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=1&signature=JSCompartment%3A%3Awrap%28JSContext*%2C%20js%3A%3AValue*%29 Thunderbird also sees this - mostly of the 0 mozjs.dll JSCompartment::wrap js/src/jscompartment.cpp:190 1 mozjs.dll JSCompartment::wrap js/src/jscompartment.cpp:315 2 mozjs.dll JS_WrapObject js/src/jsapi.cpp:1249 variety, as in bp-9ee49f39-958a-4ed5-9fb7-4c8cd2110311 The other, eg bp-fe8c7a5f-8a26-4e54-ac6e-dc3062110118, is 0 mozjs.dll JSCompartment::wrap js/src/jscompartment.cpp:190 1 mozjs.dll JS_WrapValue js/src/jsapi.cpp:1256 2 xul.dll mozJSComponentLoader::ImportInto js/src/xpconnect/loader/mozJSComponentLoader.cpp:1562 3 xul.dll mozJSComponentLoader::Import js/src/xpconnect/loader/mozJSComponentLoader.cpp:1385 4 xul.dll nsXPCComponents_Utils::Import js/src/xpconnect/src/xpccomponents.cpp:3793 5 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:102
Whiteboard: [compartments][softblocker] → [compartments][softblocker][tbird crash]
#23 crash for 4.0 and apparently climbing
Keywords: topcrash
(In reply to comment #21) > bp-74b6004c-a0cc-452c-afc7-6217c2110318 0x4 using FF 4.0rc1 on vista is my > first occurrence of this crash afaik. to be explicit - I've been running various trunk builds continuously for months (it's not like I only just started using 4.0). Also, at time of crash I had ~300 tabs ----- 0x4 Mac and linux crashes with signature and frame 1 JSCompartment::wrap bp-7d640768-87f2-42ae-844e-0a46f2110318 App Notes WebGL? GL Context? GL Context+ WebGL+ bp-0c26149d-4c6c-4ca6-b7e7-2b63b2110317 ---- 0x0 Mac and linux crashes have JSContext::wrapPendingException for frame 1 bp-07b11e33-8287-41fd-afc7-d95e82110317 bp-91af44ab-d2b9-4940-af05-f03a02110316 Frame Module Signature [Expand] Source 0 XUL JSCompartment::wrap js/src/jscompartment.cpp:241 1 XUL JSContext::wrapPendingException js/src/jscntxt.cpp:2039 2 XUL js::AutoCompartment::enter js/src/jswrapper.cpp:392 3 XUL JS_EnterCrossCompartmentCall js/src/jsapi.cpp:1185 4 XUL JSAutoEnterCompartment::enter js/src/jsapi.cpp:1225 5 XUL nsXPCWrappedJSClass::CallMethod js/src/xpconnect/src/xpcwrappedjsclass.cpp:1318
Summary: Crash in [@ JSCompartment::wrap(JSContext*, js::Value*) ] [@ JSCompartment::wrap ] → Crash in [@ JSCompartment::wrap(JSContext*, js::Value*) ], [@ JSCompartment::wrap] (Mac and linux)
> #23 crash for 4.0 and apparently climbing until #18 top crasher in 4.0 over the last 3 days.
Summary: Crash in [@ JSCompartment::wrap(JSContext*, js::Value*) ], [@ JSCompartment::wrap] (Mac and linux) → Crash in [@ JSCompartment::wrap(JSContext*, js::Value*) ] [@ JSCompartment::wrap] mainly with Firebug (Mac) or Adblock Plus (Windows) or Video Download Helper (both)
dmandelin - have we looked at this at all? Do we know anything?
(In reply to comment #25) > dmandelin - have we looked at this at all? Do we know anything? Not much. See comment 14 for the first look. The population has changed since then: 0x4 is the most common crash address now. Those crash here: 226 JSObject *global; 227 if (cx->hasfp()) { 228 global = cx->fp()->scopeChain().getGlobal(); 229 } else { 230 global = cx->globalObject; 231 OBJ_TO_INNER_OBJECT(cx, global); ^^^^^^^^^^ crash here 232 if (!global) 233 return false; 234 } OBJ_TO_INNER_OBJECT reads &global->clasp, and offsetof(JSObject, clasp) is 4, so this is an NPE on |cx->globalObject|. So this might be pretty simple: we need to check for null before innerizing as well. But there is also a comment saying that parenting all wrappers to the global is very cheesy, so maybe we should be doing something else entirely. Andreas, does it seem right to just add another null check?
I'm a little wary of that... I don't know of any contexts that we create that have a null globalObject.
(In reply to comment #27) > I'm a little wary of that... I don't know of any contexts that we create that > have a null globalObject. Q. Do our invariants allow null globalObject? i.e., are you saying that's a straight-out bug? This crash is somewhat correlated with a bunch of add-ons--maybe they are creating these contexts with null globalObjects. If so, how should we guard against that? Get back to the authors, or cover for it ourselves?
(In reply to comment #28) > This crash is somewhat correlated with a bunch of add-ons David, Is there a list of the add-ons that MAY be causing this crash? I'm trying to identify which of my installed add-ons may be the culprit(s), but this process is very time consuming and a list of potential crash-causing add-ons, based on the aggregate information of all reported crashes of this type, would be very welcome
(In reply to comment #29) > (In reply to comment #28) > > This crash is somewhat correlated with a bunch of add-ons > > David, > Is there a list of the add-ons that MAY be causing this crash? I'm trying to > identify which of my installed add-ons may be the culprit(s), but this process > is very time consuming and a list of potential crash-causing add-ons, based on > the aggregate information of all reported crashes of this type, would be very > welcome For Windows, see http://bit.ly/hFGYtS, click "Correlations", and scroll down to the list of addons. For Mac/Linux, same, but URL is http://bit.ly/dOiKDo Let me know if you can't find them. The big ones are currently Firbug, Adblock Plus, and Video DownloadHelper, but there are several more.
jorge, is there an easy to work though this list and identify which of these addons have binary components? 41 48 (87/180) vs. 7 (3739/57509) {b9db16a4-6edc-47ec-a1f4-b86292ed211d} (Video DownloadHelper, https://addons.mozilla.org/addon/3006) 33 45 (81/180) vs. 12 (6757/57509) {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} (Adblock Plus, https://addons.mozilla.org/addon/1865) 17 19 (34/180) vs. 2 (1073/57509) firebug@software.joehewitt.com (Firebug, https://addons.mozilla.org/addon/1843) 15 18 (32/180) vs. 3 (1998/57509) {D4DD63FA-01E4-46a7-B6B1-EDAB7D6AD389} (Download Statusbar, https://addons.mozilla.org/addon/26) 14 17 (31/180) vs. 3 (1810/57509) {e4a8a97b-f2ed-450b-b12d-ee082ba24781} (Greasemonkey, https://addons.mozilla.org/addon/748) 13 15 (27/180) vs. 2 (1417/57509) {DDC359D1-844A-42a7-9AA1-88A850A938A8} (DownThemAll!, https://addons.mozilla.org/addon/201) 12 37 (67/180) vs. 25 (14549/57509) {CAFEEFAC-0016-0000-0024-ABCDEFFEDCBA} 10 12 (21/180) vs. 2 (880/57509) {dc572301-7619-498c-a57d-39143191b318} (Tab Mix Plus, https://addons.mozilla.org/addon/1122) 8 19 (34/180) vs. 11 (6519/57509) {CAFEEFAC-0016-0000-0021-ABCDEFFEDCBA} 8 13 (24/180) vs. 5 (2840/57509) personas@christopher.beard (Personas, https://addons.mozilla.org/addon/10900) 8 12 (21/180) vs. 4 (2290/57509) {3112ca9c-de6d-4884-a869-9855de68056c} (Google Toolbar, https://addons.mozilla.org/addon/6249) 7 9 (17/180) vs. 2 (1196/57509) {1018e4d6-728f-4b20-ad56-37578a4de76b} (Flagfox, https://addons.mozilla.org/addon/5791) 7 9 (16/180) vs. 2 (911/57509) foxmarks@kei.com (Xmarks (formerly Foxmarks), https://addons.mozilla.org/addon/2410) 7 8 (14/180) vs. 1 (778/57509) piclens@cooliris.com (Cooliris, https://addons.mozilla.org/addon/5579) 7 8 (14/180) vs. 1 (468/57509) {c45c406e-ab73-11d8-be73-000a95be3b12} (Web Developer, https://addons.mozilla.org/addon/60) 7 13 (23/180) vs. 6 (3632/57509) {CAFEEFAC-0016-0000-0017-ABCDEFFEDCBA} 6 8 (15/180) vs. 2 (1174/57509) {CAFEEFAC-0016-0000-0007-ABCDEFFEDCBA} (Java Console, http://java.sun.com/javase/downloads/) 6 7 (12/180) vs. 1 (537/57509) {a7c6cf7f-112c-4500-a7ea-39801a327e5f} (FireFTP, https://addons.mozilla.org/addon/684) 6 21 (37/180) vs. 15 (8461/57509) {CAFEEFAC-0016-0000-0023-ABCDEFFEDCBA} 6 19 (35/180) vs. 13 (7234/57509) {CAFEEFAC-0016-0000-0020-ABCDEFFEDCBA} 5 9 (17/180) vs. 4 (2276/57509) {CAFEEFAC-0016-0000-0015-ABCDEFFEDCBA} (Java Console, http://java.sun.com/javase/downloads/) 5 8 (15/180) vs. 3 (1457/57509) {CAFEEFAC-0016-0000-0016-ABCDEFFEDCBA} (Java Console, http://java.sun.com/javase/downloads/) 5 7 (13/180) vs. 2 (1236/57509) {19503e42-ca3c-4c27-b1e2-9cdb2170ee34} (FlashGot, https://addons.mozilla.org/addon/220) 5 6 (10/180) vs. 1 (311/57509) isreaditlater@ideashower.com (Read It Later, https://addons.mozilla.org/addon/7661)
Cooliris has binary components and a binary plugin. Google Toolbar has binary components. Java Console most likely has binaries, but I didn't install it. The rest don't have any binaries. FWIW, that looks more like a list of the top add-ons by usage, so maybe there's no strong correlation to an add-on.
I poked around a bit on mxr too. Is it possible we might also get hit by addons that don't ship binary components, but call into os/third party .dlls that they find available on the system? here is what got me thinking about that idea in the downloadhelper code https://mxr.mozilla.org/addons/source/3006/components/dhConvertMgr.js#169 the numbers for a lot of the windows os .dll's are also higher that in the general population in the list at http://bit.ly/hFGYtS
Crash Signature: [@ JSCompartment::wrap(JSContext*, js::Value*) ] [@ JSCompartment::wrap]
I have a crash dump. How should I share it?
(In reply to comment #34) > I have a crash dump. How should I share it? zip/gzip it and use the add an attachment link above.
Crash Signature: [@ JSCompartment::wrap(JSContext*, js::Value*) ] [@ JSCompartment::wrap] → [@ JSCompartment::wrap(JSContext*, js::Value*) ] [@ JSCompartment::wrap]
I'm getting a file too large error. The file is 355,418,174 bytes.
(In reply to comment #36) > I'm getting a file too large error. The file is 355,418,174 bytes. Do you have a website where you could host it? Alternatively, I think you could share it with me via Dropbox.
Attached patch Patch (obsolete) — — Splinter Review
Robert, thanks for sending the dump and getting this back on the radar. After looking at that (it's another of the NPE set, which I said was the most common kind earlier) and talking to Luke, I'm sure this is the right thing to do. Note also that this code will be obviated by compartment per global.
Attachment #545467 - Flags: review?(luke)
Comment on attachment 545467 [details] [diff] [review] Patch Review of attachment 545467 [details] [diff] [review]: ----------------------------------------------------------------- I think you'll want to report an error before returning false in both these cases. As for the particular error to report, you could copy what GetGlobalForScopeChain does.
Attachment #545467 - Flags: review?(luke) → review+
Attached patch Patch v2 (obsolete) — — Splinter Review
Decided to kill off the redundancy while I'm at it.
Attachment #545467 - Attachment is obsolete: true
Attachment #545565 - Flags: review?(luke)
Comment on attachment 545565 [details] [diff] [review] Patch v2 Review of attachment 545565 [details] [diff] [review]: ----------------------------------------------------------------- Good idea. One suggestion is to use the name NULLABLE_OBJ_TO_INNER_OBJECT since this gives a more direct indication as to the extra checking being performed vs. the generic adjective "safe".
Attachment #545565 - Flags: review?(luke) → review+
Whiteboard: [compartments][softblocker][tbird crash] → [inbound][compartments][softblocker][tbird crash]
Backed out for breaking opt builds on m-i.
Whiteboard: [inbound][compartments][softblocker][tbird crash] → [compartments][softblocker][tbird crash]
Attached patch Patch v3 — — Splinter Review
v2 bounced off m-i because of linker errors in gcc.
Attachment #545565 - Attachment is obsolete: true
Attachment #546022 - Flags: review?(luke)
Attachment #546022 - Flags: review?(luke) → review+
Whiteboard: [compartments][softblocker][tbird crash] → [inbound][compartments][softblocker][tbird crash]
http://hg.mozilla.org/mozilla-central/rev/ecb74109d719
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [inbound][compartments][softblocker][tbird crash] → [compartments][softblocker][tbird crash]
Target Milestone: --- → mozilla8
It is #20 top browser crasher in 7.0a2.
blocking2.0: .x+ → ---
status-firefox7: --- → affected
(In reply to Scoobidiver from comment #45) > It is #20 top browser crasher in 7.0a2. If the patch proves to be a good fix, should we consider escalating it into a nearer release? Pinging Asa. /be
Comment on attachment 546022 [details] [diff] [review] Patch v3 nominating for Aurora and Beta to see if we can get this to users a bit sooner considering that it's a topcrash with high-profile add-ons.
Attachment #546022 - Flags: approval-mozilla-beta?
Attachment #546022 - Flags: approval-mozilla-aurora?
Comment on attachment 546022 [details] [diff] [review] Patch v3 Approved for beta and aurora per today's meeting, please land asap (especially on beta).
Attachment #546022 - Flags: approval-mozilla-beta?
Attachment #546022 - Flags: approval-mozilla-beta+
Attachment #546022 - Flags: approval-mozilla-aurora?
Attachment #546022 - Flags: approval-mozilla-aurora+
This is actually already in beta8 and aurora9 as it landed on mozilla-central when Firefox 8 was in development (and hg transplanting says it is already applied). Clearing approvals as they aren't needed.
Attachment #546022 - Flags: approval-mozilla-beta+
Attachment #546022 - Flags: approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: