Version: (using KDE KDE 3.3.92) Installed from: Compiled From Sources Compiler: gcc (GCC) 3.3.4 (Debian 1:3.3.4-9) OS: Linux A <div><img/><img/></div> structure is restructured into <div><div><img/><img/></div></div> using a JavaScript (complete testcase follows - the page can also be found at http://www.odahoda.pink.puppetmaster.homelinux.org/konqcrash.html). The 1nd level <div> gets a class with 'position: relative' assigned during the transformation (no crash if the CSS rule is removed). It does only crash with image tags inside. No crash with text contents or 'fake' images (<div>s with background-image, using the same images as in the crash case).
Created attachment 9650 [details] minimal example of a HTML page that crashes Konqueror
The original page that triggered the crash in 3.4 beta2 worked fine in 3.3.1 Now I checked the testcase in Konqueror 3.3.1 and it crashes there, too. Perhaps more than one bug is involved... And the backtrace of 3.4 beta2 is (only kdelibs where compiled with debugging on): Using host libthread_db library "/lib/tls/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread 1098975584 (LWP 16586)] [KCrash handler] #3 0x4168bee9 in raise () from /lib/tls/libc.so.6 #4 0x41799edc in ?? () from /lib/tls/libc.so.6 #5 0x00000002 in ?? () #6 0x4168d781 in abort () from /lib/tls/libc.so.6 #7 0x00000000 in ?? () #8 0x00000020 in ?? () #9 0x00000000 in ?? () #10 0x00000000 in ?? () #11 0x00000000 in ?? () #12 0x00000000 in ?? () #13 0x00000000 in ?? () #14 0x00000000 in ?? () #15 0x00000000 in ?? () #16 0x00000000 in ?? () #17 0x00000000 in ?? () #18 0x00000000 in ?? () #19 0x00000000 in ?? () #20 0x00000000 in ?? () #21 0x00000000 in ?? () #22 0x00000000 in ?? () #23 0x00000000 in ?? () #24 0x00000000 in ?? () #25 0x00000000 in ?? () #26 0x00000000 in ?? () #27 0x00000000 in ?? () #28 0x00000000 in ?? () #29 0x00000000 in ?? () #30 0x00000000 in ?? () #31 0x00000000 in ?? () #32 0x00000000 in ?? () #33 0x00000000 in ?? () #34 0x00000000 in ?? () #35 0x00000000 in ?? () #36 0x00000000 in ?? () #37 0x00000000 in ?? () #38 0x00000000 in ?? () #39 0x00000000 in ?? () #40 0x416d13f9 in _IO_file_write () from /lib/tls/libc.so.6 #41 0x416d061f in _IO_do_write () from /lib/tls/libc.so.6 #42 0x416d1577 in _IO_file_xsputn () from /lib/tls/libc.so.6 #43 0x41799edc in ?? () from /lib/tls/libc.so.6 #44 0x4179a860 in __after_morecore_hook () from /lib/tls/libc.so.6 #45 0x084882e8 in ?? () #46 0xbfffd758 in ?? () #47 0x416d62b0 in free () from /lib/tls/libc.so.6 #48 0x4179a860 in __after_morecore_hook () from /lib/tls/libc.so.6 #49 0x084882e8 in ?? () #50 0x41799edc in ?? () from /lib/tls/libc.so.6 #51 0x41799edc in ?? () from /lib/tls/libc.so.6 #52 0x084882e8 in ?? () #53 0x41685443 in __assert_fail () from /lib/tls/libc.so.6 #54 0xbffff99a in ?? () #55 0x4178bbf4 in in6addr_loopback () from /lib/tls/libc.so.6 #56 0x41f742ca in DOM::AttributeImpl::setValue(DOM::DOMStringImpl*, DOM::ElementImpl*)::__PRETTY_FUNCTION__ () from /opt/kde3.4-beta2/lib/libkhtml.so.4 #57 0x000001ea in ?? () #58 0x41f74360 in DOM::ElementImpl::setAttributeMap(DOM::NamedAttrMapImpl*)::__PRETTY_FUNCTION__ () from /opt/kde3.4-beta2/lib/libkhtml.so.4 #59 0x4178bbf4 in in6addr_loopback () from /lib/tls/libc.so.6 #60 0x41f7373b in DOM::DocumentImpl::~DocumentImpl()::__PRETTY_FUNCTION__ () from /opt/kde3.4-beta2/lib/libkhtml.so.4 #61 0x084882e8 in ?? () #62 0x41ff2c34 in __JCR_LIST__ () from /opt/kde3.4-beta2/lib/libkhtml.so.4 #63 0xbfffd960 in ?? () #64 0x41da4f4a in DOM::ElementImpl::attach (this=0x0) at dom_elementimpl.cpp:490
Can reproduce. Konq hangs a long time, then crashes. I get no Dr. Konqui, though.
==27502== Invalid read of size 4 ==27502== at 0x41030114: (within /lib/tls/libc-2.3.2.so) ==27502== by 0x4103B26E: __assert_fail (in /lib/tls/libc-2.3.2.so) ==27502== by 0x1DB187F3: DOM::ElementImpl::attach() (dom_elementimpl.cpp:490) ==27502== by 0x1DB13381: DOM::NodeBaseImpl::attach() (dom_nodeimpl.cpp:1389) ==27502== by 0x1DB18842: DOM::ElementImpl::attach() (dom_elementimpl.cpp:497) ==27502== by 0x1DB1305E: DOM::NodeBaseImpl::appendChild(DOM::NodeImpl*, int&) (dom_nodeimpl.cpp:1297) ==27502== by 0x1DCB9541: DOM::Node::appendChild(DOM::Node const&) (dom_node.cpp:294) ==27502== by 0x1DC16AE1: KJS::DOMNodeProtoFunc::tryCall(KJS::ExecState*, KJS::Object&, KJS::List const&) (kjs_dom.cpp:482) ==27502== by 0x1DC10931: KJS::DOMFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (kjs_binding.cpp:107) ==27502== by 0x1DDE31CF: KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (object.cpp:70) ==27502== by 0x1DDAF92B: KJS::FunctionCallNode::evaluate(KJS::ExecState*) const (nodes.cpp:850) ==27502== by 0x1DDB4DC0: KJS::ExprStatementNode::execute(KJS::ExecState*) (nodes.cpp:1953) ==27502== by 0x1DDBB7A0: KJS::SourceElementsNode::execute(KJS::ExecState*) (nodes.cpp:3073) ==27502== by 0x1DDB4BE5: KJS::BlockNode::execute(KJS::ExecState*) (nodes.cpp:1915) ==27502== by 0x1DDBAA15: KJS::FunctionBodyNode::execute(KJS::ExecState*) (nodes.cpp:2919) ==27502== by 0x1DDDE8B6: KJS::DeclaredFunctionImp::execute(KJS::ExecState*) (function.cpp:579) ==27502== by 0x1DDDDA73: KJS::FunctionImp::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (function.cpp:354) ==27502== by 0x1DDE31CF: KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (object.cpp:70) ==27502== by 0x1DC78653: KJS::JSEventListener::handleEvent(DOM::Event&) (kjs_events.cpp:109) ==27502== by 0x1DB115F9: DOM::NodeImpl::handleLocalEvents(DOM::EventImpl*, bool) (dom_nodeimpl.cpp:652) ==27502== by 0x1DB1091D: DOM::NodeImpl::dispatchGenericEvent(DOM::EventImpl*, int&) (dom_nodeimpl.cpp:428) ==27502== by 0x1DB107B4: DOM::NodeImpl::dispatchEvent(DOM::EventImpl*, int&, bool) (dom_nodeimpl.cpp:402) ==27502== by 0x1DB10C90: DOM::NodeImpl::dispatchHTMLEvent(int, bool, bool) (dom_nodeimpl.cpp:483) ==27502== by 0x1DB97B1B: khtml::RenderImage::notifyFinished(khtml::CachedObject*) (render_image.cpp:417) ==27502== by 0x1DC04CC4: khtml::CachedImage::ref(khtml::CachedObjectClient*) (loader.cpp:466) ==27502== by 0x1DB97E58: khtml::RenderImage::updateImage(khtml::CachedImage*) (render_image.cpp:462) ==27502== by 0x1DB98131: khtml::RenderImage::updateFromElement() (render_image.cpp:495) ==27502== by 0x1DB4807A: DOM::HTMLImageElementImpl::attach() (html_imageimpl.cpp:190) ==27502== by 0x1DB13381: DOM::NodeBaseImpl::attach() (dom_nodeimpl.cpp:1389) ==27502== by 0x1DB18842: DOM::ElementImpl::attach() (dom_elementimpl.cpp:497) ==27502== by 0x1DB13381: DOM::NodeBaseImpl::attach() (dom_nodeimpl.cpp:1389) ==27502== by 0x1DB18842: DOM::ElementImpl::attach() (dom_elementimpl.cpp:497) ==27502== by 0x1DB13381: DOM::NodeBaseImpl::attach() (dom_nodeimpl.cpp:1389) ==27502== by 0x1DB18842: DOM::ElementImpl::attach() (dom_elementimpl.cpp:497) ==27502== by 0x1DB1305E: DOM::NodeBaseImpl::appendChild(DOM::NodeImpl*, int&) (dom_nodeimpl.cpp:1297) ==27502== by 0x1DCB9541: DOM::Node::appendChild(DOM::Node const&) (dom_node.cpp:294) ==27502== by 0x1DC16AE1: KJS::DOMNodeProtoFunc::tryCall(KJS::ExecState*, KJS::Object&, KJS::List const&) (kjs_dom.cpp:482) ==27502== by 0x1DC10931: KJS::DOMFunction::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (kjs_binding.cpp:107) ==27502== by 0x1DDE31CF: KJS::Object::call(KJS::ExecState*, KJS::Object&, KJS::List const&) (object.cpp:70) ==27502== by 0x1DDAF92B: KJS::FunctionCallNode::evaluate(KJS::ExecState*) const (nodes.cpp:850)
*** This bug has been marked as a duplicate of 89277 ***
not fixed.
hmm, might be an another example where it may make sense to delay onload emission for images a bit..
The patch I just attached to bug #107052 fixes this as well
SVN commit 428727 by orlovich: Merge in http://www.cs.cornell.edu/~maksim/WC/changesets/1771.html from WC. This prevent recursion bugs happening in onload events. (Note: the current WebCore code is different, and I know at least some bugs it fixes, but I don't want to make 2 changes at once. Better get this tested for a bit before moving on) Fixes #107052, and the crash in #99480, as well as some synthetic onload testcases I cooked up. Some testcases upcoming up BUG:107052 CCBUG:99480 M +3 -0 html/html_documentimpl.cpp M +35 -5 rendering/render_image.cpp M +3 -0 rendering/render_image.h M +61 -1 xml/dom_docimpl.cpp M +10 -0 xml/dom_docimpl.h
SVN commit 428728 by orlovich: Add a modified version of the test from #99480. The crash is gone, but it shows an another bug: we're emitting wayy too many onload events there. I believe this is because during the movement we detach the render tree, and the new one omits the onload again -> moving the emission to content should fix it. I put in a limit in the testcase to make it work reliably. (And made it use test images from data:/) Also add an another test for what got fixed: loading an image from an onload event now emits onload properly. Just a synthetic unit test, no BR I couldn't get the testcase for #107052 in shape for the regtester, seem to rely on pecularities of using the http slave to trigger. CCBUG:99480 A baseline/events/img_onload_double.html-dom AM baseline/events/img_onload_double.html-dump.png A baseline/events/img_onload_double.html-render A baseline/unsorted/99480.html-dom AM baseline/unsorted/99480.html-dump.png A baseline/unsorted/99480.html-render A tests/events/img_onload_double.html A tests/unsorted/99480.html ** trunk/tests/khtmltests/regression/baseline/events/img_onload_double.html-dump.png #property changes Name: svn:mime-type + application/octet-stream ** trunk/tests/khtmltests/regression/baseline/unsorted/99480.html-dump.png #property changes Name: svn:mime-type + application/octet-stream
Revised state of things after the above fix
SVN commit 444350 by orlovich: Make onload event emission happen from the HTMLImageElementImpl and not from RenderImage. fixes #99480. Many thanks to Dirk for making me try to explain my earlier attempts. BUG:99480 M +43 -2 html/html_imageimpl.cpp M +8 -2 html/html_imageimpl.h M +0 -39 rendering/render_image.cpp M +0 -4 rendering/render_image.h M +7 -9 xml/dom_docimpl.cpp M +5 -5 xml/dom_docimpl.h