Bug 38193

Summary: [Qt] Segfault when unloading a plugin which creates a QScriptEngine
Product: WebKit Reporter: Kent Hansen <kent.hansen>
Component: JavaScriptCoreAssignee: Nobody <webkit-unassigned>
Status: RESOLVED INVALID    
Severity: Normal CC: cmarcelo, hausmann, rion4ik, steveire
Priority: P2 Keywords: Qt, QtTriaged
Version: 528+ (Nightly build)   
Hardware: PC   
OS: All   
Attachments:
Description Flags
Testcase (Linux) none

Description Kent Hansen 2010-04-27 04:31:29 PDT
Originated from http://bugreports.qt.nokia.com/browse/QTBUG-9622

There are two issues (that I know of) that's causing JavaScriptCore not to gracefully unload:
- g_identifierTableSpecific in runtime/Identifier.cpp is never deleted. This is a problem on the Qt port, since we use QThreadStorage to implement ThreadSpecific. The QApplication destructor will attempt to destroy the data, but by this time the QtScript library has been unloaded, causing a crash.
- The scavenger thread in wtf/FastMalloc.cpp is not shut down gracefully.

The same happens when loading entire QtWebKit from a plugin, of course.

1) Is loading from a plugin a use case we want to support? If so;
2) What's needed to make it happen? We need a robust solution, not just work-arounds for the above two issues. In particular, loading -> unloading -> loading must be supported. It will also have implications for WebKit in general (e.g. people can't just go and add a global variable; they have to make sure it doesn't break loading/unloading).
Comment 1 Kent Hansen 2010-04-27 04:35:32 PDT
Created attachment 54410 [details]
Testcase (Linux)

Uncompress under JavaScriptCore/qt/tests, build qtscriptplugin/theplugin, and then qtscriptplugin. Segfaults due to the g_identifierTableSpecific issue.
Comment 2 steveire 2010-04-27 12:54:24 PDT
The motivation for the original bug comes from Grantlee and the intention was to be able to have only a plugin depend on QtScript, and the core library depend only on QtCore. 

Diagram at the bottom of http://grantlee.org/apidox/using_and_deploying.html.

I'd prefer that to remain (or become, it seems) possible and supported. I guess it would also be possible to link grantlee_core to libQtScript, but only if really necessary. I don't know if depending on libQtScript brings in a libQtWebkit or libQtGui dependency?

Grantlee uses libQtScript to allow users to implement custom parsing and rendering of textual markup content. Disabling the use of the QtScript plugin is an easy way to prevent users from begin able to do those things in cases where it could cause security holes.

All the best,

Steve.
Comment 3 Jocelyn Turcotte 2014-02-03 03:16:25 PST
=== 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.