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

Status: RESOLVED INACTIVE

(Core :: XPConnect, defect)

Description

[Josh Matthews [:jdm]]

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!).

Comment 1

[Josh Matthews [:jdm]]

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.

Comment 2

[Josh Matthews [:jdm]]

Attachment: 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.

Comment 4

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.