Closed Bug 806206 Opened 13 years ago Closed 12 years ago

crash in JSObject::global

Categories

(Core :: JavaScript Engine, defect)

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

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla21
Tracking Flags:
Tracking Status
firefox18 --- unaffected
firefox19 + verified
firefox20 + verified
firefox21 --- verified

People

(Reporter: scoobidiver, Assigned: nbp)

References

Details

(5 keywords, Whiteboard: [js:inv:p2])

Crash Data

Attachments

(2 files)

Reduced testcase (blank page, crash with FF19+)
338 bytes, text/html
Details
InlineFrameIterator: provide default scope chain value if unused.
1.02 KB, patch
dvander
: review+
bajaj
: approval-mozilla-aurora+
bajaj
: approval-mozilla-beta+
Details | Diff | Splinter Review
It's a low volume crash but it started spiking from 19.0a1/20121012030610. The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=99898ec9976a&tochange=1301a72b1c39 It's likely a regression from bug 797977. Signature JSObject::global() More Reports Search UUID 36900b50-ff18-4251-a95a-08ad22121028 Date Processed 2012-10-28 11:02:53 Uptime 5910 Last Crash 1.4 weeks before submission Install Age 1.6 hours since version was first installed. Install Time 2012-10-28 08:40:22 Product Firefox Version 19.0a1 Build ID 20121027030611 Release Channel nightly OS Windows NT OS Version 6.1.7601 Service Pack 1 Build Architecture x86 Build Architecture Info AuthenticAMD family 16 model 6 stepping 3 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 App Notes AdapterVendorID: 0x1002, AdapterDeviceID: 0x9712, AdapterSubsysID: 394917aa, AdapterDriverVersion: 8.712.0.0 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers+ EMCheckCompatibility True Adapter Device ID 0x9712 Total Virtual Memory 4294836224 Available Virtual Memory 3602018304 System Memory Use Percentage 46 Available Page File 4282822656 Available Physical Memory 1582616576 Frame Module Signature Source 0 mozjs.dll JSObject::global js/src/jsobjinlines.h:1203 1 mozjs.dll JS_GetScriptedGlobal js/src/jsapi.cpp:7328 2 xul.dll nsGlobalWindow::CallerGlobal dom/base/nsGlobalWindow.cpp:6082 3 xul.dll nsGlobalWindow::CallerInnerWindow dom/base/nsGlobalWindow.cpp:6095 4 xul.dll nsGlobalWindow::PostMessageMoz dom/base/nsGlobalWindow.cpp:6414 5 xul.dll nsGlobalWindow::PostMessageMoz dom/base/nsGlobalWindow.cpp:6403 6 xul.dll NS_InvokeByIndex_P xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:70 7 xul.dll XPCWrappedNative::CallMethod js/xpconnect/src/XPCWrappedNative.cpp:2418 8 xul.dll XPC_WN_CallMethod js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1488 9 @0x1a77312f 10 @0xffffff81 11 mozjs.dll EnterIon js/src/ion/Ion.cpp:1427 12 mozjs.dll js::ion::CanEnter js/src/ion/Ion.cpp:1338 13 mozjs.dll JS_WrapObject js/src/jsapi.cpp:1501 14 xul.dll XPCConvert::NativeData2JS js/xpconnect/src/XPCConvert.cpp:319 15 mozjs.dll js::Invoke js/src/jsinterp.cpp:412 16 mozjs.dll mozjs.dll@0x102c4f 17 xul.dll nsXPCWrappedJSClass::CallMethod js/xpconnect/src/XPCWrappedJSClass.cpp:1420 18 xul.dll nsCOMPtr_base::assign_with_AddRef obj-firefox/xpcom/build/nsCOMPtr.cpp:49 19 xul.dll nsXPCWrappedJS::CallMethod js/xpconnect/src/XPCWrappedJS.cpp:580 More reports at: https://crash-stats.mozilla.com/report/list?signature=JSObject%3A%3Aglobal%28%29
Whiteboard: [js:inv:p2]
Attachment #698049 - Attachment description: Reduced testcase → Reduced testcase (blank page, crash with FF19+)
We agree that bug 826035 sounds like a dupe, so we've tentatively marked it as such. Also, this has risen in the FF19 crash list, so marking appropriately.
Crash Signature: [@ JSObject::global()] → [@ JSObject::global()] [@ JS_GetScriptedGlobal(JSContext*)]
status-firefox20: --- → affected
tracking-firefox19: ? → +
tracking-firefox20: ? → +
Keywords: reproducible, topcrash
Regression window Last Good: 79e5f4ec83ae First Bad: ebeca12019a2 Triggered by: ebeca12019a2 Nicolas B. Pierron — Bug 797977 - Rename StackIter::fp() to StackIter::interpFrame(). r=luke
Crash Signature: [@ JSObject::global()] [@ JS_GetScriptedGlobal(JSContext*)] → [@ JSObject::global()] [@ JS_GetScriptedGlobal(JSContext*)] [@ JSObject::global() const]
OS: Windows 7 → All
Hardware: x86 → All
Nicolas - Firefox 19 is now on beta, and we've only got a couple of weeks to resolve. Can you take a look as soon as possible?
Assignee: general → nicolas.b.pierron
I cannot reproduce this bug with the attached test case on both beta and nightly.
I tried the latest Nightly and it crashed. Are you on Windows?
I am testing on Linux, with my own build as I cannot run any of the build produced by tbpl.
Maybe the bug is Windows-specific.
I have been able to reproduce this bug on Linux x86 (first bad revision, debug build), with the provided test case. Assertion failure: v.isObject(), at /home/nicolas/mozilla/ionmonkey/js/src/ion/IonFrames.cpp:1040 Program received signal SIGSEGV, Segmentation fault. 0xf6b0059c in js::ion::InlineFrameIterator::scopeChain (this=0xffff6a0c) at /home/nicolas/mozilla/ionmonkey/js/src/ion/IonFrames.cpp:1040 1040 JS_ASSERT(v.isObject()); (gdb) bt #0 0xf6b0059c in js::ion::InlineFrameIterator::scopeChain (this=0xffff6a0c) at /home/nicolas/mozilla/ionmonkey/js/src/ion/IonFrames.cpp:1040 #1 0xf69574e3 in js::StackIter::scopeChain (this=0xffff69c0) at /home/nicolas/mozilla/ionmonkey/js/src/vm/Stack.cpp:1702 #2 0xf66fde4b in JS_GetScriptedGlobal (cx=0xe415be40) at /home/nicolas/mozilla/ionmonkey/js/src/jsapi.cpp:7320 #3 0xf4ce450c in nsGlobalWindow::CallerGlobal (this=0xe0aa7170) at /home/nicolas/mozilla/ionmonkey/dom/base/nsGlobalWindow.cpp:6080 #4 0xf4ce457b in nsGlobalWindow::CallerInnerWindow (this=0xe0aa7170) at /home/nicolas/mozilla/ionmonkey/dom/base/nsGlobalWindow.cpp:6093 #5 0xf4ce56af in nsGlobalWindow::PostMessageMoz (this=0xe0aa7170, aMessage=..., aOrigin=..., aCx=0xe415be40) at /home/nicolas/mozilla/ionmonkey/dom/base/nsGlobalWindow.cpp:6412 #6 0xf4ce569d in nsGlobalWindow::PostMessageMoz (this=0xda2f8e20, aMessage=..., aOrigin=..., aCx=0xe415be40) at /home/nicolas/mozilla/ionmonkey/dom/base/nsGlobalWindow.cpp:6400 #7 0xf5c32ba4 in NS_InvokeByIndex_P () from /home/nicolas/mozilla/ionmonkey/_build/t/bug806206/x86/gcc45/dbg/dist/bin/libxul.so #8 0xf53041ba in CallMethodHelper::Invoke (this=0xffff6f20) at /home/nicolas/mozilla/ionmonkey/js/xpconnect/src/XPCWrappedNative.cpp:3108 #9 0xf530229e in CallMethodHelper::Call (this=0xffff6f20) at /home/nicolas/mozilla/ionmonkey/js/xpconnect/src/XPCWrappedNative.cpp:2442 #10 0xf5302153 in XPCWrappedNative::CallMethod (ccx=..., mode=XPCWrappedNative::CALL_METHOD) at /home/nicolas/mozilla/ionmonkey/js/xpconnect/src/XPCWrappedNative.cpp:2408 #11 0xf530eb5a in XPC_WN_CallMethod (cx=0xe415be40, argc=2, vp=0xffff70fc) at /home/nicolas/mozilla/ionmonkey/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1488 #12 0xea190ff6 in ?? () Cannot access memory at address 0xffffff8b (gdb) f 11 #11 0xf530eb5a in XPC_WN_CallMethod (cx=0xe415be40, argc=2, vp=0xffff70fc) at /home/nicolas/mozilla/ionmonkey/js/xpconnect/src/XPCWrappedNativeJSOps.cpp:1488 1488 return XPCWrappedNative::CallMethod(ccx); (gdb) call js_DumpBacktrace(cx) #0 ??? #1 (nil) http://ir.ebaystatic.com/z/au/b2o4ckknqq4vhch2fknpv0hgt.js:6 (0xdb028600 @ 133) #2 (nil) http://ir.ebaystatic.com/z/au/b2o4ckknqq4vhch2fknpv0hgt.js:6 (0xdb028580 @ 29) #3 (nil) http://ir.ebaystatic.com/z/au/b2o4ckknqq4vhch2fknpv0hgt.js:6 (0xdb028480 @ 13) The problem can be a wrong snapshot, or a scope chain which is not defined as expected.
Keywords: assertion
Hardware: All → x86
Ok, the problem is likely coming from the fact that the script which is making the native function call does not have any scope chain, and the analysis reports that we don't need any scope chain so we bake in the undefined constant in the scope chain. When reading the scope chain in js::ion::InlineFrameIterator::scopeChain, we read undefined and not an object as expected. The solution would be to add a global() function on StackIter which either takes it from the scopeChain in case of an interpreter frame or from the IonActivation's compartment.
Duplicate the behavior of StackFrame in case where the scope chain is not defined, which is to use the callee.environment as a substitute for the missing scope chain. The major difference is that when the scope chain is observed on the StackFrame, it is cached there and we cannot do so with an Ion frame because the undefined constant is hard coded in the snapshot. This patch is made on top of the first bad changeset.
Attachment #699488 - Flags: review?(dvander)
Attachment #699488 - Flags: review?(dvander) → review+
https://hg.mozilla.org/mozilla-central/rev/e16c82303ab3
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Comment on attachment 699488 [details] [diff] [review] InlineFrameIterator: provide default scope chain value if unused. [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 797977. User impact if declined: crash. Testing completed (on m-c, etc.): https://hg.mozilla.org/mozilla-central/rev/e16c82303ab3 Risk to taking this patch (and alternatives if risky): Small, as this copy the current behavior of js::StackFrame. String or UUID changes made by this patch: N/A
Attachment #699488 - Flags: approval-mozilla-beta?
Attachment #699488 - Flags: approval-mozilla-aurora?
Comment on attachment 699488 [details] [diff] [review] InlineFrameIterator: provide default scope chain value if unused. Approving on aurora, and in preparation fr beta landing based on lowering of crash volume. Lets keep a close eye to see the crashes go down on aurora and no new regressions are caused before taking on beta.
Attachment #699488 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Attachment #699488 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Verified as fixed on Firefox 19 Beta 3 (20130123083802) with the reduced testcase: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0 Mozilla/5.0 (X11; Linux i686; rv:19.0) Gecko/20100101 Firefox/19.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:19.0) Gecko/20100101 Firefox/19.0 While there are no post-fix crashes for the other two signatures, there are some for JSObject::global() - https://crash-stats.mozilla.com/report/list?signature=JSObject%3A%3Aglobal%28%29. The stack trace seems to the same as for the initial crashes, so this bug might not have been fully fixed. Can someone that worked on this fix please look at the recent crashes and confirm/infirm it's the same bug?
Whiteboard: [js:inv:p2] → [js:inv:p2][qa?]
(In reply to Ioana Budnar [QA] from comment #20) > While there are no post-fix crashes for the other two signatures, there are > some for JSObject::global() - > https://crash-stats.mozilla.com/report/ > list?signature=JSObject%3A%3Aglobal%28%29. I haven't seen post-fix crashes. Please provide a crash ID.
(In reply to Ioana Budnar [QA] from comment #22) > https://crash-stats.mozilla.com/report/index/8f865bd0-e4af-497f-959f- > c35d22130122 Nightly elm is still in 20.0 and doesn't contain the fix.
(In reply to Scoobidiver from comment #23) > (In reply to Ioana Budnar [QA] from comment #22) > > https://crash-stats.mozilla.com/report/index/8f865bd0-e4af-497f-959f- > > c35d22130122 > Nightly elm is still in 20.0 and doesn't contain the fix. Thanks for the info. Apparently all the crashes with buildIDs post-fix are for elm.
status-firefox19: fixed → verified
Whiteboard: [js:inv:p2][qa?] → [js:inv:p2]
QA Contact: ioana.budnar
Verified as fixed on Friefox 20 Beta 1 (20130220104816): Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0 No new crashes in Socorro either.
Verified as fixed on Firefox 20 beta 2 (20130227063501): Mozilla/5.0 (Windows NT 6.1; rv:20.0) Gecko/20100101 Firefox/20.0 Mozilla/5.0 (X11; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:20.0) Gecko/20100101 Firefox/20.0 There is one Firefox 20 beta crash in Socorro (https://crash-stats.mozilla.com/report/index/e8afb425-a7c9-48ca-b7c5-038022130228), but it doesn't look like it's the same crash.
status-firefox20: fixed → verified
Verified as fixed on Firefox 21 RC - 20130507015204.
status-firefox21: fixed → verified
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: