xpcshell: JS exceptions that occur in functions called via xpconnect are swallowed

NEW
Unassigned

Status

()

Core
XPConnect
7 years ago
5 years ago

People

(Reporter: jdm, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
Simple way to reproduce the problem:
1. open up netwerk/test/unit/test_reentrancy.js
2. add a call to |foo();| at the start of the onStartRequest callback
3. SOLO_FILE=test_reentrancy.js make -C objdir/netwerk check-one

The test fails since the rest of onStartRequest doesn't run, but there's no indication that an exception was thrown. This is unacceptable, and has caused numerous problems with silent test failures (or pseudo-successes!).
(Reporter)

Comment 1

7 years ago
Time for the analysis - this fails for a very similar reason as bug 503244, namely that the trip from JS -> C++ -> JS is lossy (due to nsWrappedJSClass::CheckForExceptions clearing any pending exceptions) and that my_ErrorReporter in xpcshell.cpp has the typical "walk the frames, bail if there's another javascript frame in existence". In this case, since the xpcshell tests run in a JS harness, there is always a frame found.  This check is valid in some cases, but when we're just running the event loop and processing asynchronous things that call JS callbacks, the check breaks down. I think we need to look harder at the various paths we can take through nsWrappedJSClass and figure out where the best place to hide the existing frame chain is.
(Reporter)

Comment 2

7 years ago
Created attachment 535260 [details]
Sample callstack

Here's the call stack of the onStartRequest in case anything stands out. The context's exception is cleared within nsWrappedJSClass::CheckForException which is called near the bottom of CallMethod if JS_CallFunctionValue fails.

Updated

7 years ago
Duplicate of this bug: 677779
You need to log in before you can comment on or make changes to this bug.