memory leak related to setting innerHTML in onLoad

[Tobias Anton]

Hello,

attached is a testcase that triggers a memory leak in KHTML. 

It sets the innerHTML of a node and then redirects to itself by a JavaScript 
command. 

The bug is reproducible with 3.2, 3.2.2 and with safari. I used QT 3.3.0 for 
my tests.

I ran valgrind with testkhtml on that page using the options --skin=memcheck 
--leak-check=yes --show-reachable=yes --num-callers=20

The two sections that had allocated most memory might be related to the leak:

==29612== 2104032 bytes in 49194 blocks are still reachable in loss record 144 
of 145
==29612==    at 0x40164128: __builtin_vec_new (in 
/usr/lib/valgrind/valgrind.so)
==29612==    by 0x40164163: operator new[](unsigned) (in 
/usr/lib/valgrind/valgrind.so)
==29612==    by 0x41608907: QString::setLength(unsigned) 
(tools/qstring.cpp:1699)
==29612==    by 0x41608B96: QString::grow(unsigned) (tools/qstring.cpp:1790)
==29612==    by 0x4160F162: QString::operatorPlusEqHelper(char const*, 
unsigned) (tools/qstring.cpp:5360)
==29612==    by 0x4160F22E: QString::operator+=(char const*) 
(tools/qstring.cpp:5381)
==29612==    by 0x40ECEDB2: KURL::url(int, int) const 
(/data/src/kde/HEAD/qt-copy/include/qstring.h:876)
==29612==    by 0x4041EC0D: 
khtml::CSSStyleSelector::CSSStyleSelector(DOM::DocumentImpl*, QString, 
DOM::StyleSheetListImpl*, KURL const&, bool) 
(/data/src/kde/HEAD/qt-copy/include/qshared.h:50)
==29612==    by 0x40371A6E: DOM::DocumentImpl::recalcStyleSelector() 
(/data/src/kde/HEAD/qt-copy/include/qshared.h:50)
==29612==    by 0x4039FB12: DOM::HTMLDocumentImpl::determineParseMode(QString 
const&) (html_documentimpl.cpp:434)
==29612==    by 0x40339BC5: KHTMLPart::write(char const*, int) 
(khtml_part.cpp:1716)
==29612==    by 0x40336E59: KHTMLPart::slotData(KIO::Job*, QMemArray<char> 
const&) (khtml_part.cpp:1417)
==29612==    by 0x40354C4B: KHTMLPart::qt_invoke(int, QUObject*) 
(khtml_part.moc:470)
==29612==    by 0x41322A20: QObject::activate_signal(QConnectionList*, 
QUObject*) (kernel/qobject.cpp:2359)
==29612==    by 0x408D2530: KIO::TransferJob::data(KIO::Job*, QMemArray<char> 
const&) (/data/src/kde/HEAD/qt-copy/include/private/qucom_p.h:124)
==29612==    by 0x408BDCA0: KIO::TransferJob::slotData(QMemArray<char> const&) 
(job.cpp:784)
==29612==    by 0x408D2A4F: KIO::TransferJob::qt_invoke(int, QUObject*) 
(jobclasses.moc:801)
==29612==    by 0x41322A20: QObject::activate_signal(QConnectionList*, 
QUObject*) (kernel/qobject.cpp:2359)
==29612==    by 0x408AEB06: KIO::SlaveInterface::data(QMemArray<char> const&) 
(/data/src/kde/HEAD/qt-copy/include/private/qucom_p.h:124)
==29612==    by 0x408ABC9B: KIO::SlaveInterface::dispatch(int, QMemArray<char> 
const&) (slaveinterface.cpp:246)
==29612==
==29612== 3277772 bytes in 153366 blocks are still reachable in loss record 
145 of 145
==29612==    at 0x4016402F: __builtin_new (in /usr/lib/valgrind/valgrind.so)
==29612==    by 0x4016406A: operator new(unsigned) (in 
/usr/lib/valgrind/valgrind.so)
==29612==    by 0x41607DF2: QString::makeSharedNull() (tools/qstring.cpp:1361)
==29612==    by 0x41254621: QString::QString() (../include/qstring.h:836)
==29612==    by 0x41611532: __static_initialization_and_destruction_0(int, 
int) (tools/qstring.cpp:1352)
==29612==    by 0x41611834: _GLOBAL__I__ZNK5QChar7isPrintEv 
(tools/qstringlist.h:62)
==29612==    by 0x416B3EE4: (within 
/data2/data/src/kde/HEAD/qt-copy/lib/libqt-mt.so.3.3.0)
==29612==    by 0x4120D778: (within 
/data2/data/src/kde/HEAD/qt-copy/lib/libqt-mt.so.3.3.0)
==29612==    by 0x4000BBCD: call_init (in /lib/ld-2.3.2.so)
==29612==    by 0x4000BD0D: _dl_init_internal (in /lib/ld-2.3.2.so)
==29612==    by 0x40000AAC: (within /lib/ld-2.3.2.so)

I looked at DOM::DocumentImpl::recalcStyleSelector() and 
DOM::HTMLDocumentImpl::determineParseMode(QString const&), but I didn't find 
any problems with that code.

Does anybody have a clue what might be causing this? Could it eventually be a 
QT bug?

Cheers
-- Tobias
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20040505/77bbb785/attachment.html>