WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
38193
[Qt] Segfault when unloading a plugin which creates a QScriptEngine
https://bugs.webkit.org/show_bug.cgi?id=38193
Summary
[Qt] Segfault when unloading a plugin which creates a QScriptEngine
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
Details
View All
Add attachment
proposed patch, testcase, etc.
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.
Top of Page
Format For Printing
XML
Clone This Bug