Bug 49720 – [Qt] Not possible to catch C++ exception thrown from slot called from JS

• Component: JavaScriptCore
• Status: RESOLVED INVALID

[Kent Hansen]

The attached application aborts with

"terminate called after throwing an instance of 'int'"

even though the call to evaluateJavaScript() (which calls the slot that throws the exception) is inside a try..catch.

Last tested against r72178.

This only happens when the JIT is enabled. It seems the C++ runtime is not able to properly unwind the stack and find the exception handler in that case.

The question is whether this is something that can be fixed in the JIT. If not, it seems like we need to introduce try..catch in the QtWebKit bridge (and convert the C++ exception to a JS exception, possibly). Alternatively, we can document that throwing exceptions from C++ is not supported in this case (e.g. the application developer should introduce try..catch on his side where necessary).

[Kent Hansen]

Created attachment 74221 [details]
Testcase

[Kent Hansen]

Found the same issue in relation to LLVM: http://old.nabble.com/C%2B%2B-Exception-Handling-Problem-td22427938.html

Solution from above thread: "My guess here is that there are JITted functions in your stack. If that's the case, you need to set the ExceptionHandling flag of LLVM on. This will make the JIT generate dwarf tables for JITted code, and libgcc
will be able to unwind these functions."

So the ideal solution for us would be to have dwarf table generation in JSC (that would have to be explicitly enabled, e.g. through a QWebSettings flag).

[Jocelyn Turcotte]

=== Bulk closing of Qt bugs ===

If you believe that this bug report is still relevant for a non-Qt port of webkit.org, please re-open it and remove [Qt] from the summary.

If you believe that this is still an important QtWebKit bug, please fill a new report at https://bugreports.qt-project.org and add a link to this issue. See http://qt-project.org/wiki/ReportingBugsInQt for additional guidelines.

[Darin Adler]

Moving all JavaScriptGlue bugs to JavaScriptCore. The JavaScriptGlue framework itself is long gone. And most of the more recent bugs put in this component were put there by people who thought this was for some other aspect of “JavaScript glue” and have nothing to do with the actual original reason for the existence of this component, which was an OS-X-only framework named JavaScriptGlue.