Re: [webkit-dev] ScopeChainNode leak?

2009-06-19 Thread Kelemen Balázs

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

2008-07-31 Thread Kelemen Balázs
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

2008-09-01 Thread Kelemen Balázs

 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

2008-12-08 Thread Kelemen Balázs
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