KJS CPU Guard locks konqueror

[David Faure]

On a page with a long JS execution (I had KJS_VERBOSE enabled), konqueror hanged.
Apparently, doing a malloc from an alarm handler is only good for getting a deadlock.

(gdb) bt
#0  0x413f3fb5 in nanosleep () from /lib/i686/libpthread.so.0
#1  0x4096b85e in lock (m=0x40) at /mnt/devel/kde/kdecvs/kdelibs/kdecore/malloc/x86.h:32
#2  0x40969a5b in malloc (bytes=64) at /mnt/devel/kde/kdecvs/kdelibs/kdecore/malloc/malloc.c:5511
#3  0x414ea37e in operator new(unsigned) () from /usr/lib/libstdc++.so.5
#4  0x414ea4ad in operator new[](unsigned) () from /usr/lib/libstdc++.so.5
#5  0x41019f02 in QString::setLength(unsigned) (this=0xbfffcd30, newLen=24) at qstring.cpp:1677
#6  0x4102122e in QString::fromUtf8(char const*, int) (utf8=0x41bfbd3a "alarmhandler", len=12) at qstring.cpp:5265
#7  0x40191c25 in kdbgstream::operator<<(char const*) (this=0xbfffce20, string=0x41bfbd3a "alarmhandler") at kdebug.h:199
#8  0x41b78a8d in KJSCPUGuard::alarmHandler(int) () at /mnt/devel/kde/kdecvs/kdelibs/khtml/ecma/kjs_proxy.cpp:395
#9  0x413f35ce in __pthread_sighandler () from /lib/i686/libpthread.so.0
#10 0x415653b8 in __libc_sigaction () from /lib/i686/libc.so.6
#11 0x40969a76 in malloc (bytes=128) at /mnt/devel/kde/kdecvs/kdelibs/kdecore/malloc/malloc.c:5514
#12 0x414ea37e in operator new(unsigned) () from /usr/lib/libstdc++.so.5
#13 0x414ea4ad in operator new[](unsigned) () from /usr/lib/libstdc++.so.5
#14 0x41019f02 in QString::setLength(unsigned) (this=0xbfffd320, newLen=40) at qstring.cpp:1677
#15 0x4102122e in QString::fromUtf8(char const*, int) (utf8=0x41bf6981 "DOMNodeList::tryGet ", len=20) at qstring.cpp:5265
#16 0x40191c25 in kdbgstream::operator<<(char const*) (this=0xbfffd470, string=0x41bf6981 "DOMNodeList::tryGet ")
    at /mnt/devel/kde/kdecvs/kdelibs/kdecore/kdebug.h:199
#17 0x41b1f1e0 in KJS::DOMNodeList::tryGet(KJS::ExecState*, KJS::Identifier const&) const (this=0x85d1430, exec=0xbfffdc20, p=@0xbfffd560)
    at /mnt/devel/kde/kdecvs/kdelibs/khtml/ecma/kjs_dom.cpp:603
#18 0x41b17156 in KJS::DOMObject::get(KJS::ExecState*, KJS::Identifier const&) const (this=0x85d1430, exec=0xbfffdc20, p=@0xbfffd560)
    at /mnt/devel/kde/kdecvs/kdelibs/khtml/ecma/kjs_binding.cpp:48
#19 0x41ce216f in KJS::ObjectImp::get(KJS::ExecState*, unsigned) const (this=0x85d1430, exec=0xbfffdc20, propertyName=148)
    at /mnt/devel/kde/kdecvs/kdelibs/kjs/object.cpp:186
#20 0x41ce9760 in KJS::Reference::getValue(KJS::ExecState*) const (this=0xbfffd600, exec=0xbfffdc20) at /mnt/devel/kde/kdecvs/kdelibs/kjs/reference.cpp:141
#21 0x41ca60a3 in KJS::Node::evaluate(KJS::ExecState*) const (this=0x85e95b8, exec=0xbfffdc20) at /mnt/devel/kde/kdecvs/kdelibs/kjs/nodes.cpp:122

The signal happened while we were in a malloc, and apparently there is a 
lock there, i.e. it's not reentrant.

There is no way we can show a dialog from a signal handler, there is always going
to be a malloc around...

I just talked to Lars about this, and his suggestion is: set a flag in the signal handler,
and check for that flag regularly inside KJS (not sure where exactly). This
seems to be the only solution to prevent such deadlocks.
Koos: what do you think?

-- 
David FAURE, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).