Re: [webkit-dev] ScopeChainNode leak?
Hi Andrew, I have tried your changes, and it worked for me fine - even without removing the #ifndef NDEBUG from ScopeChainNode.h. I ran sunspider, jsc-regression tests, and I browsed with QtLauncher (I use Qt port on Linux), and I have not found any regression or crash. (I forced the build environment to build JavaScriptCore in interpreter mode.) Valgrind sad the leak had been eliminated. Do you plan to file a bug? Are you still working on the problem? Balazs Andrew Webster wrote: I've been tracking down a memory leak I've noticed on pages using JQuery (and others). Valgrind pointed out that it is ScopeChainNodes that are leaking. I have tracked this down to functions that are not dereffing their ScopeChainNode when they are deleted. I notice that the JSFunction dtor contains code that is supposed to do this, but it is ifdef'd out for non-JIT platforms (of which I am one of): #if ENABLE(JIT) // JIT code for other functions may have had calls linked directly to the code for this function; these links // are based on a check for the this pointer value for this JSFunction - which will no longer be valid once // this memory is freed and may be reused (potentially for another, different JSFunction). if (!isHostFunction()) { if (m_body && m_body->isGenerated()) m_body->generatedBytecode().unlinkCallers(); scopeChain().~ScopeChain(); } #endif If I switch this code to: if (!isHostFunction()) { #if ENABLE(JIT) // JIT code for other functions may have had calls linked directly to the code for this function; these links // are based on a check for the this pointer value for this JSFunction - which will no longer be valid once // this memory is freed and may be reused (potentially for another, different JSFunction). if (m_body && m_body->isGenerated()) m_body->generatedBytecode().unlinkCallers(); #endif scopeChain().~ScopeChain(); } it seems to solve the memory leak. However, the release build doesn't work properly unless I remove the #ifndef NDEBUG from ScopeChain.h so that the pointers and such are cleared on delete. I also thought that it might be a good idea to call scopeChain().~ScopeChain() when the scope is re-assigned in setScopeChain or clearScopeChain, however this seems to introduce problems. Can anyone comment on why scopeChain().~ScopeChain() is wrapped in #if ENABLE(JIT)? Is there a better solution then what I've done? Will I face another leak by not dereffing in setScopeChain/cleanScopeChain? Thanks, Andrew ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev This message was sent using IMP, the Internet Messaging Program. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Leak in plugin management
I find a leak with valgrind when running QtLauncher and load pages that requires plugins. It is that the m_module member in WebCore::PluginPackage class is not freed. I took a look at the code and realized that this member must freed with a delay through freeLibrarySoon method that is callen from the destructor. I debuged QtLauncher and discovered that this member is not freed anyway. The destructor runs many times but the unloadModule function that should free the member had never been reached. I tested it though load pages like youtube and "http://szotar.sztaki.hu/index.hu.jhtml"; in QtLauncher when it was run under gdb (these pages require flash, mplayer and java plugins). Then I load simple html pages and local files but the member had been still unfreed. I use the Qt port of Webkit under linux. It is a real leak, or I just misunderstood the logic of plugin management? Regards Kelemen Balázs This message was sent using IMP, the Internet Messaging Program. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Robotized QtLauncher
Hi Webkit developers! I made modifications in QtLauncher for possibility of taking large tests and searching memory leaks or other errors with tools like valgrind. In my version when the first parameter is an existing file with the suffix "urllist" (for example: urls.urllist) QtLauncher loads the urls that it contains. The file must be a simple text file with one url in each line and the suffix must be "urllist". When the parameter is not a file it works like before. I found many problems in webkit with this tool. Usually these problems appears with an assertion hit. Te most recently is: ASSERTION FAILED: m_frame->document()->parsing() (../../../WebCore/loader/FrameLoader.cpp:1865 void WebCore::FrameLoader::addData(const char*, int)) I think this can be useful and I want to continue work on this, so I ask you about your opinion. Is it possible to merge this code into the trunk (for except into a separate directory like WebKit/qt/QtLauncher_test)? Anyway it could be useful for me if somebody would check it and affirm that my code is correct and the problems are in Webkit itself (I really believe in it but there are some errors that I can not reproducate manually.) My changes are just a few lines in WebKit/qt/QtLauncher/main.cpp (and one in QtLauncher.pro). I attach my changes and a backtrace of the error I show above. Thanks! Kelemen Balázs This message was sent using IMP, the Internet Messaging Program. Index: QtLauncher.pro === --- QtLauncher.pro (revision 35941) +++ QtLauncher.pro (working copy) @@ -3,8 +3,13 @@ CONFIG -= app_bundle CONFIG += uitools DESTDIR = ../../../bin +INCPATH += $$PWD/../../../JavaScriptCore/wtf include(../../../WebKit.pri) Index: main.cpp === --- main.cpp (revision 35941) +++ main.cpp (working copy) @@ -42,6 +42,15 @@ #include +#include +#include +#include +#include +#include +#include +#include +using namespace std; + class WebPage : public QWebPage { public: @@ -87,6 +96,10 @@ return view->page(); } +QWebView *webView() const { +return view; +} + protected slots: void changeLocation() { @@ -322,12 +335,80 @@ return loader.createWidget(classId, view()); } +class UrlLoader : public QObject +{ +Q_OBJECT +public: +UrlLoader(const QWebView* view, const QString& inputFile, const QString& outputFile) +: m_outputFile(outputFile.toStdString().c_str()) +{ +m_view = const_cast(view); +init(inputFile.toStdString()); +} + +~UrlLoader() +{ + m_outputFile.flush(); + m_outputFile.close(); +} + + +public slots: +void loadNext() +{ +QString *qstr; +if(getUrl(qstr)) { +QUrl url(*qstr, QUrl::StrictMode); +if(url.isValid()) { +cout<<"Loading "<toStdString()<<" .."<toStdString()<load(url); +} else { +loadNext(); +} +} else { +disconnect(m_view, 0, this, 0); +} +} + +private: +void init(const string& inputFile) +{ +ifstream file(inputFile.c_str()); +char buffer[1024]; +int i = 0; +while(true) { +file.getline(buffer, 1024); +if(file.eof()) +break; +m_urls.insert(i++, new QString(buffer)); +} +m_index = 0; +file.close(); +} + +bool getUrl(QString*& qstr) +{ +if(m_index == m_urls.size()) { +return false; +} +qstr = m_urls[m_index++]; +return true; +} + +private: +WTF::Vector m_urls; +int m_index; +QWebView* m_view; +ofstream m_outputFile; +}; + #include "main.moc" int main(int argc, char **argv) { QApplication app(argc, argv); -QString url = QString("%1/%2").arg(QDir::homePath()).arg(QLatin1String("index.html")); +QString defaultUrl = QString("%1/%2").arg(QDir::homePath()).arg(QLatin1String("index.html")); QWebSettings::setMaximumPagesInCache(4); @@ -341,13 +422,28 @@ QWebSettings::globalSettings()->setAttribute(QWebSettings::PluginsEnabled, true); QWebSettings::globalSettings()->setAttribute(QWebSettings::DeveloperExtrasEnabled, true); +QString arg1, arg2; const QStringList args = app.arguments(); -if (args.count() > 1) -url = args.at(1); +if (args.count() > 1) { +arg1 = args.at(1); +if(args.count() > 2) + arg2 = args.at(2); +else + arg2 = QString("loaded_urls.txt"); +} else { +arg1 = defaultUrl; +} -MainWindow window(url); -window.show(); - -r
[webkit-dev] Out-of-memory handling
Hi Webkit Folks! We are thinking about how to deal with out-of-memory situation. A tempting approach would be using exception handling. E.g., what if we could catch a bad_alloc exception? Would there be any way to simply force WebKit from the browser to "shutdown" itself? When I say shutdown, I mean exiting in an elegant way, e.g., we could save history and other important information to disk (so that when the browser restarts, some info does not get lost). Particularly, we are working with the Qt port, but we are interested in a general solution as well. Best regards, Balázs Kelemen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev