"Assertion failure: !cx->isExceptionPending()" with Proxy

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
--
critical
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: Jesse Ruderman, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, testcase})

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

Firefox Tracking Flags

(firefox19-)

Details

(Whiteboard: [fuzzblocker:isExceptionPending])

Attachments

(3 attachments)

(Reporter)

Description

5 years ago
Created attachment 682724 [details]
testcase (asserts fatally when loaded)

Assertion failure: !cx->isExceptionPending(), at js/src/jsinterp.cpp:3804

I'm guessing this is a JavaScript Engine bug (despite DOM stuff in the testcase) because the stack is js/src/ from #17 up.
(Reporter)

Updated

5 years ago
Whiteboard: [fuzzblocker:isExceptionPending]
(Reporter)

Comment 1

5 years ago
Created attachment 682725 [details]
stack
tracking-firefox19: --- → ?
Yeah, IsDuckTypedErrorObject didn't realize that HasProperty can call back into JS now.
tracking-firefox19: ? → ---

Updated

5 years ago
tracking-firefox19: --- → ?
Why HasProperty asserts while GetProperty doesn't?
Because the proxy in the test case only has a 'has' trap that throws.
Created attachment 682817 [details]
testcase without Proxy

'has' trap is not a essence.
Even Proxy is not essential because this testcase crashes at js_ReportUncaughtException.

Comment 6

5 years ago
What user impact does this bug have? Was this testcase reduced from a popular website? Or do we expect it to affect websites?
Cannot reproduce on release builds because this is an assertion failure.
(Reporter)

Comment 8

5 years ago
This testcase was reduced from something the fuzzer dreamed up.
In release builds the failure would manifest by random calls from JS silently terminating the JS execution without actually throwing an exception the web page can catch.
I thought js_ReportUncaughtException will be called only when the web page didn't catch the exception. Is it wrong?
(Reporter)

Comment 11

5 years ago
"random" in what way?
"random" in the sense that it's impossible for the page author to predict which call will fail.  Basically, the first one after someone doesn't report (via returning false) a pending exception...

> I thought js_ReportUncaughtException will be called only when the web page didn't catch
> the exception. Is it wrong?

That's probably right; the problems start when an exception is pending but never thrown because a false return is swallowed.
(In reply to Boris Zbarsky (:bz) from comment #12)
> > I thought js_ReportUncaughtException will be called only when the web page didn't catch
> > the exception. Is it wrong?
> 
> That's probably right; the problems start when an exception is pending but
> never thrown because a false return is swallowed.
Even if the exception is thrown, it will not be visible from the Web page anyway. So I think this bug will not affect websites. Could you write a Web-visible STR?
I haven't looked into the code carefully enough.  Does it currently guarantee that if it set an exception on the JSContext it will return false?  If not, then it's definitely web-visible.
Not enough known user impact to warrant tracking for release. We'd accept a low-risk uplift, however.
tracking-firefox19: ? → -
(Reporter)

Comment 16

5 years ago
WFM on mozilla-central
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.