Bug 24458 – QWebView memory leak

• Component: WebKit Qt
• Status: RESOLVED FIXED

[Benjamin Meyer]

Run the following application and watch as memory usage for the application goes up and up. :)

#include <QtGui/QtGui>
#include <QtWebKit/QtWebKit>

int main(int argc, char **argv) {
    QApplication application(argc, argv);
    while (true) {
        QWebView view;
        view.show();
    }
    return application.exec();
}

[Benjamin Meyer]

A more valid test case:

#include <QtGui/QtGui>
#include <QtWebKit/QtWebKit>

int main(int argc, char **argv)
{
    QApplication application(argc, argv);
    
    while (true) {
        QWebView *view = new QWebView;
        view->show();
        delete view;
    }

    return application.exec();
}

[Balazs Kelemen]

Another test case that loads the same page through one WebView in a loop.
It shows that memory usage goes up and up by WebKit itself.

#include <QWebView>
#include <QtGui>

class Loader : public QObject {
    Q_OBJECT
public:
    Loader(QWebView* view, const QUrl& url) : m_view(view), m_url(url) {}

public slots:
    void loadNext()
    {
        m_view->load(m_url);
    }
    
private:
    QWebView* m_view;
    QUrl m_url;
};

#include "main.moc"

int main(int argc, char **argv)
{
    QApplication application(argc, argv);
    QWebView view;
    QUrl url("http://www.webkit.org");
    Loader loader(&view, url);
    QObject::connect(&view, SIGNAL(loadFinished(bool)), &loader,
SLOT(loadNext()));
    view.load(url);
    view.show();

    return application.exec();
}

[Haso Keric]

this bug makes it useless to have a Web Application run in Qt Webkit (it can only run for 1-2 hours and you have to restart it) i hope they fix this soon, someone =) that knows how to fix it.

[Robert Hogan]

Created attachment 30804 [details]
valgrind output from the test case

valgrind output from the test case - lots of unreachable blocks created from qt

[Robert Hogan]

Created attachment 30805 [details]
valgrind output

at icefox's suggestion added processEvents() to the testcase so that the X11 handles would get flushed:

#include <QtGui/QtGui>
#include <QtWebKit/QtWebKit>

int main(int argc, char **argv)
{
    QApplication application(argc, argv);

    for (int i=0; i < 100; i++)
     {
        QWebView *view = new QWebView;
        view->show();
        application.processEvents();
        delete view;
    }

    exit(0);
}

[Robert Hogan]

unless i'm mistaken, adding the processEvents() to the testcase removes the memory leak. so is the original case an actual bug?

[Robert Hogan]

Created attachment 30807 [details]
valgrind output

adding a qt quit() to the test case reduces the leaks to just a couple of X11 items. In practice memory use increases hardly at all, especially compared to the original test case.

#include <QtGui/QtGui>
#include <QtWebKit/QtWebKit>

int main(int argc, char **argv)
{
    QApplication application(argc, argv);

    for (int i=0; i < 1000; i++)
//     while (true)
     {
        QWebView *view = new QWebView;
        application.processEvents();
        view->show();
        delete view;
    }
    application.quit();
}

[Holger Freyther]

(In reply to comment #4)
> Created an attachment (id=30804) [review]
> valgrind output from the test case
> 
> valgrind output from the test case - lots of unreachable blocks created from qt

Okay, I have used lazlos example with Plugins On/Off, WebDevelopers On/Off, Cache On/Off and I don't really see anything bad in top %MEM is not increasing, virt memory is not increasing...

Looking at the valgrind log doesn't show any obvious thing from within WebKit. E.g. it would be interesting to see how replacing QWebView with QTextEdit will keep the memleak/make it go away wih ben's example.

[Holger Freyther]

And a good tool to see where allocations came from is memprof (get version 0.6).

[Robert Hogan]

i ran valgrind against the case in comment #2 and the biggest culprit was plain to see! The leak is from 1000 url loads.

==16523== 11,331,196 (9,702,200 direct, 1,628,996 indirect) bytes in 8,725 blocks are definitely lost in loss record 421 of 421
==16523==    at 0x40269EE: operator new(unsigned int) (vg_replace_malloc.c:224)
==16523==    by 0x474FCD3: WebCore::FontFallbackList::fontDataAt(WebCore::Font const*, unsigned int) const (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x45EE0F0: WebCore::Font::cachePrimaryFont() const (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x45EE137: WebCore::Font::ascent() const (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x46A1B01: WebCore::RenderListMarker::calcPrefWidths() (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x469E550: WebCore::RenderListItem::updateMarkerLocation() (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x469E611: WebCore::RenderListItem::calcPrefWidths() (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x466BEFA: WebCore::RenderBox::minPrefWidth() const (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x46598CD: WebCore::RenderBlock::calcBlockPrefWidths() (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x4665859: WebCore::RenderBlock::calcPrefWidths() (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x466BEFA: WebCore::RenderBox::minPrefWidth() const (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==    by 0x46598CD: WebCore::RenderBlock::calcBlockPrefWidths() (in /home/robert/qtsdk-2009.01/qt/lib/libQtWebKit.so.4.5.0)
==16523==
==16523== LEAK SUMMARY:
==16523==    definitely lost: 9,706,770 bytes in 8,752 blocks.
==16523==    indirectly lost: 2,240,423 bytes in 19,186 blocks.
==16523==      possibly lost: 117,083 bytes in 88 blocks.
==16523==    still reachable: 2,951,274 bytes in 18,305 blocks.
==16523==         suppressed: 0 bytes in 0 blocks.

[Benjamin Meyer]

As shown the first few examples were not valid.  The only valid example of a memory leak has been fixed (the font leak)  If there is another leak and a reproducible case is found another bug can be opened.  For those who are waiting for the leak fix it will be in Qt 4.5.2.