If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

"ASSERTION: Why are we being called with a pending exception?" in nsJSContext::CompileEventHandler after pushState

RESOLVED DUPLICATE of bug 637116

Status

()

Core
DOM
RESOLVED DUPLICATE of bug 637116
7 years ago
7 years ago

People

(Reporter: Jesse Ruderman, Assigned: mrbkap)

Tracking

(Blocks: 2 bugs, {assertion, testcase})

Trunk
x86
Mac OS X
assertion, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

7 years ago
Created attachment 501938 [details]
testcase 1

###!!! ASSERTION: Why are we being called with a pending exception?: '!::JS_IsExceptionPending(mContext)', file dom/base/nsJSEnvironment.cpp, line 2014
(Reporter)

Updated

7 years ago
Group: core-security
(Reporter)

Updated

7 years ago
Attachment #501938 - Attachment is private: false
(Reporter)

Comment 1

7 years ago
Created attachment 501939 [details]
stack for testcase 1
(Reporter)

Comment 2

7 years ago
Created attachment 501940 [details]
testcase 2

Triggers the same assertion as testcase 1, plus this fatal assertion:

Assertion failure: compartment mismatched, at js/src/jscntxtinlines.h:542

(JS_SetPendingException)
(Reporter)

Comment 3

7 years ago
Created attachment 501941 [details]
stacks for testcase 2

Comment 4

7 years ago
Make mismatches always blocking 2.0

Updated

7 years ago
status2.0: --- → ?

Comment 5

7 years ago
Are you sure this is TM tip/m-c? I think I fixed this bug (the mismatch part).
(Reporter)

Comment 6

7 years ago
The "compartment mismatch" part seems to be gone (mozilla-central badef0f336d2).

Comment 7

7 years ago
I can't judge the severity of the rest of the bug. jst?
status2.0: ? → ---
Assignee: nobody → jst
Whiteboard: [sg:needinfo]
(Reporter)

Updated

7 years ago
Whiteboard: [sg:needinfo]
This is not a security bug. Per mrbkap's debugging the problem here is that we call pushState() on an iframe, running on the calling window's context, then pushState() does its JSON serialization on the iframe's context and ends up leaving a pending exception hanging on that context. Then, next time we end up doing things on the iframe's context we see the pending exception and assert.

While this is wrong, it's effectively harmless. Opening this bug up. mrbkap will look at this once Firefox 4 is out the door.
Assignee: jst → mrbkap
Group: core-security
This has been fixed, presumably by Bug 637116.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 637116
You need to log in before you can comment on or make changes to this bug.