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

Kent Hansen
Reported 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).
Attachments
Testcase (Linux) (1.47 KB, application/gzip)
2010-04-27 04:35 PDT, Kent Hansen
no flags
Kent Hansen
Comment 1 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.
steveire
Comment 2 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.
Jocelyn Turcotte
Comment 3 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.
Note You need to log in before you can comment on or make changes to this bug.