The default bug view has changed. See this FAQ.

Assertion failure: !cx->isExceptionPending(), at js/src/jscntxtinlines.h:299

RESOLVED FIXED in mozilla10



6 years ago
6 years ago


(Reporter: mats, Assigned: gal)


({crash, testcase})

crash, testcase
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(Not tracked)



(2 attachments)



6 years ago
Created attachment 565839 [details]
Testcase (CRASH on load)

1. load the attached testcase in a Firefox debug build

Assertion failure: !cx->isExceptionPending(), at js/src/jscntxtinlines.h:299

Bug occurs in a local mozilla-central debug build on Linux64


6 years ago
Attachment #565839 - Attachment mime type: text/html → application/xhtml+xml

Comment 1

6 years ago
Oh wow, there is a stack implosion going on when that assertion finally fires. My backtrace is at frame 1500 and still counting.

Comment 2

6 years ago
The nsIDOMNode_RemoveChild quickstub is apparently returning JS_TRUE, but an exception is set on the context. Curiouser and curiouser.

Comment 3

6 years ago
Specifically, at some point there is an error thrown from somewhere under nsGenericElement::RemoveChild (from the mutation events, presumably), so an exception is set on the context, but RemoveChild doesn't know this and naively returns NS_OK.

Comment 4

6 years ago
As far as I can tell, is the code that triggers the mutation events that are presumably throwing here. It's tricky to catch the actual problem behaviour in gdb, though, since the stack is so huge and there doesn't seem to be any differentiating behaviour beforehand that I can conditionally break with.


6 years ago
OS: Linux → All

Comment 5

6 years ago
That's about as far as my analysis can go at this point, so someone else is more than welcome to take up where I left off.


6 years ago
Assignee: general → nobody
Component: JavaScript Engine → DOM
QA Contact: general → general
Hardware: x86_64 → All


6 years ago
Severity: critical → major
So... Presumably xpconnect is not exactly returning an error nsresult from the nested JS invocation but also not reporting the exception?  That seems broken, if so....

Is it expected that mutation listener exceptions will report through to the caller that did the mutation?  Or should they be reported once the listener returns?

Comment 7

6 years ago
You want to break on JS_SetPendingException in these cases.

#0  JS_SetPendingException (cx=0x10d821c90, v={data = {asBits = 18445477441092330328, debugView = {payload47 = 4777976664, tag = JSVAL_TAG_OBJECT}, s = {payload = {i32 = 483009368, u32 = 483009368, why = 483009368}}, asDouble = -nan(0xb80011cca2358), asPtr = 0xfffb80011cca2358, asWord = 18445477441092330328}}) at /Users/gal/workspace/mozilla-central/js/src/jsapi.cpp:6054
#1  0x0000000102c0de8b in js_ErrorToException (cx=0x10d821c90, message=0x10b649490 "too much recursion", reportp=0x7fff5faff080, callback=0x102bc9c23 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0) at /Users/gal/workspace/mozilla-central/js/src/jsexn.cpp:1197
#2  0x0000000102bccbfd in ReportError (cx=0x10d821c90, message=0x10b649490 "too much recursion", reportp=0x7fff5faff080, callback=0x102bc9c23 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0) at /Users/gal/workspace/mozilla-central/js/src/jscntxt.cpp:639
#3  0x0000000102bccd99 in js_ReportErrorNumberVA (cx=0x10d821c90, flags=0, callback=0x102bc9c23 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0, errorNumber=26, charArgs=1, ap=0x7fff5faff140) at /Users/gal/workspace/mozilla-central/js/src/jscntxt.cpp:989
#4  0x0000000102b8a254 in JS_ReportErrorNumber (cx=0x10d821c90, errorCallback=0x102bc9c23 <js_GetErrorMessage(void*, char const*, unsigned int)>, userRef=0x0, errorNumber=26) at /Users/gal/workspace/mozilla-central/js/src/jsapi.cpp:5790
#5  0x0000000102bcbb26 in js_ReportOverRecursed (maybecx=0x10d821c90) at /Users/gal/workspace/mozilla-central/js/src/jscntxt.cpp:727
#6  0x0000000102bd37aa in JSCompartment::wrap (this=0x11b1a6000, cx=0x10d821c90, vp=0x7fff5faff348) at /Users/gal/workspace/mozilla-central/js/src/jscompartment.cpp:197
#7  0x0000000102bd417c in JSCompartment::wrap (this=0x11b1a6000, cx=0x10d821c90, objp=0x7fff5faff548) at /Users/gal/workspace/mozilla-central/js/src/jscompartment.cpp:363
#8  0x0000000102b974c8 in JS_WrapObject (cx=0x10d821c90, objp=0x7fff5faff548) at /Users/gal/workspace/mozilla-central/js/src/jsapi.cpp:1389
#9  0x0000000101a3532a in nsJSContext::CallEventHandler (this=0x10d820c40, aTarget=0x10b6e0890, aScope=0x11ccc4060, aHandler=0x11cce9088, aargv=0x10b6849e0, arv=0x7fff5faff810) at /Users/gal/workspace/mozilla-central/dom/base/nsJSEnvironment.cpp:1927
#10 0x0000000101ae3f54 in nsJSEventListener::HandleEvent (this=0x10b6272b0, aEvent=0x10b684900) at /Users/gal/workspace/mozilla-central/dom/src/events/nsJSEventListener.cpp:211
#11 0x0000000101804c49 in nsEventListenerManager::HandleEventSubType (this=0x10b627220, aListenerStruct=0x10b627258, aListener=0x10b6272b0, aDOMEvent=0x10b684900, aCurrentTarget=0x10b6e0890, aPhaseFlags=6, aPusher=0x7fff5faffc70) at /Users/gal/workspace/mozilla-central/content/events/src/nsEventListenerManager.cpp:736
#12 0x0000000101804e4e in nsEventListenerManager::HandleEventInternal (this=0x10b627220, aPresContext=0x1079dea20, aEvent=0x10b684970, aDOMEvent=0x7fff5faffc50, aCurrentTarget=0x10b6e0890, aFlags=6, aEventStatus=0x7fff5faffc58, aPusher=0x7fff5faffc70) at /Users/gal/workspace/mozilla-central/content/events/src/nsEventListenerManager.cpp:790
#13 0x0000000101836ff7 in nsEventListenerManager::HandleEvent (this=0x10b627220, aPresContext=0x1079dea20, aEvent=0x10b684970, aDOMEvent=0x7fff5faffc50, aCurrentTarget=0x10b6e0890, aFlags=6, aEventStatus=0x7fff5faffc58, aPusher=0x7fff5faffc70) at nsEventListenerManager.h:160
#14 0x00000001018371a3 in nsEventTargetChainItem::HandleEvent (this=0x11b1ee330, aVisitor=@0x7fff5faffc40, aFlags=6, aMayHaveNewListenerManagers=false, aPusher=0x7fff5faffc70) at /Users/gal/workspace/mozilla-central/content/events/src/nsEventDispatcher.cpp:215
#15 0x00000001018353f1 in nsEventTargetChainItem::HandleEventTargetChain (this=0x11b1ee330, aVisitor=@0x7fff5faffc40, aFlags=6, aCallback=0x0, aMayHaveNewListenerManagers=false, aPusher=0x7fff5faffc70) at /Users/gal/workspace/mozilla-central/content/events/src/nsEventDispatcher.cpp:344
#16 0x00000001018363ec in nsEventDispatcher::Dispatch (aTarget=0x10b6e0890, aPresContext=0x1079dea20, aEvent=0x10b684970, aDOMEvent=0x10b684900, aEventStatus=0x7fff5faffdfc, aCallback=0x0, aTargets=0x0) at /Users/gal/workspace/mozilla-central/content/events/src/nsEventDispatcher.cpp:672
#17 0x000000010183676d in nsEventDispatcher::DispatchDOMEvent (aTarget=0x10b6e0890, aEvent=0x0, aDOMEvent=0x10b684900, aPresContext=0x1079dea20, aEventStatus=0x7fff5faffdfc) at /Users/gal/workspace/mozilla-central/content/events/src/nsEventDispatcher.cpp:735
#18 0x000000010170c275 in nsINode::DispatchEvent (this=0x10b6e0890, aEvent=0x10b684900, aRetVal=0x7fff5faffe3f) at /Users/gal/workspace/mozilla-central/content/base/src/nsGenericElement.cpp:1136
#19 0x0000000101833ded in nsPLDOMEvent::Run (this=0x10b6848c0) at /Users/gal/workspace/mozilla-central/content/events/src/nsPLDOMEvent.cpp:70
#20 0x00000001016775e4 in nsContentUtils::AddScriptRunner (aRunnable=0x10b6848c0) at /Users/gal/workspace/mozilla-central/content/base/src/nsContentUtils.cpp:4427
#21 0x0000000101833d03 in nsPLDOMEvent::RunDOMEventWhenSafe (this=0x10b6848c0) at /Users/gal/workspace/mozilla-central/content/events/src/nsPLDOMEvent.cpp:94
#22 0x00000001016d0807 in nsDocument::MutationEventDispatched (this=0x11b14d800, aTarget=0x10b6e0890) at /Users/gal/workspace/mozilla-central/content/base/src/nsDocument.cpp:7457
#23 0x000000010165a312 in mozAutoSubtreeModified::UpdateTarget (this=0x7fff5fb000a0, aSubtreeOwner=0x0, aTarget=0x0) at nsIDocument.h:1832
#24 0x000000010165a3db in mozAutoSubtreeModified::~mozAutoSubtreeModified (this=0x7fff5fb000a0) at nsIDocument.h:1826
#25 0x000000010167d257 in nsContentUtils::MaybeFireNodeRemoved (aChild=0x1079a7f80, aParent=0x10b6e0890, aOwnerDoc=0x11b14d800) at /Users/gal/workspace/mozilla-central/content/base/src/nsContentUtils.cpp:3351
#26 0x00000001017010fd in nsINode::RemoveChild (this=0x10b6e0890, aOldChild=0x1079a7f80) at /Users/gal/workspace/mozilla-central/content/base/src/nsGenericElement.cpp:526
#27 0x00000001020a0a66 in nsIDOMNode_RemoveChild (cx=0x10d821c90, argc=1, vp=0x10adb5f80) at /Users/gal/workspace/mozilla-central/debug-build/js/src/xpconnect/src/dom_quickstubs.cpp:6931
#28 0x0000000102c80e04 in js::CallJSNative (cx=0x10d821c90, native=0x1020a0863 <nsIDOMNode_RemoveChild(JSContext*, unsigned int, JS::Value*)>, args=@0x7fff5fb00490) at jscntxtinlines.h:296
#29 0x0000000102ed7f7a in CallCompiler::generateNativeStub (this=0x7fff5fb00d00) at /Users/gal/workspace/mozilla-central/js/src/methodjit/MonoIC.cpp:937
Ah, this is a regression from bug 650273 which added this code in CallEventHandler:

    if (!ac.enter(mContext, funobj) || !ff.enter() ||
        !JS_WrapObject(mContext, &target)) {
      return NS_ERROR_FAILURE;

or more precisely added the JS_WrapObject call.  The JS_WrapObject can throw, and the contract for this function is that it reports any exceptions thrown inside it; see the ReportPendingException call down lower that all error paths should fall through to.  So we just need to fix this block to report the exception.
Blocks: 650273

Comment 9

6 years ago
Created attachment 565859 [details] [diff] [review]

Comment 10

6 years ago
Comment on attachment 565859 [details] [diff] [review]

Would be nice to get this reviewed and landed since it turns up in fuzz testing.
Attachment #565859 - Flags: review?(bzbarsky)
Comment on attachment 565859 [details] [diff] [review]

Attachment #565859 - Flags: review?(bzbarsky) → review+

Comment 12

6 years ago
Assignee: nobody → gal
Flags: in-testsuite+
Whiteboard: [inbound]
Target Milestone: --- → mozilla10
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
You need to log in before you can comment on or make changes to this bug.