Bug 10855 – REGRESSION: Reproducible crash in svg/custom/evt-onload.svg under GuardMalloc

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: SVG

[Mark Rowe (bdash)]

I have seen intermittent occurrences of "DumpRenderTree(1386,0xa000cf60) malloc: ***  Deallocation of a pointer not malloced: 0x2ed85de0; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug" while running the layout tests.  After experimentation, I narrowed it down to a single test that crashes when using GuardMalloc.

atlas:~/WebKit-Devel mrowe$ DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib ./WebKitBuild/Debug/DumpRenderTree LayoutTests/svg/custom/evt-onload.svg 
Allocations will be placed on word (4 byte) boundaries.
 - Small buffer overruns may not be noticed.
 - Applications using AltiVec instructions may fail.
GuardMalloc-11
Segmentation fault
LEAK: 8 Node
LEAK: 3 RenderObject
LEAK: 1 Frame
LEAK: 23 KJS::Node


GDB says:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xce35aff8
0x013efdd7 in WebCore::SVGPaint::paintType (this=0xce35afd8) at ./ksvg2/svg/SVGPaint.h:54
54              SVGPaintType paintType() const { return m_paintType; }
(gdb) bt
#0  0x013efdd7 in WebCore::SVGPaint::paintType (this=0xce35afd8) at ./ksvg2/svg/SVGPaint.h:54
#1  0x0107623e in WebCore::StyleFillData::operator== (this=0xce382ff4, other=@0xce490ff4) at WebKit-Devel/WebCore/ksvg2/css/SVGRenderStyleDefs.cpp:58
#2  0x013f1744 in WebCore::DataRef<WebCore::StyleFillData>::operator== (this=0xce380fe4, o=@0xce48efe4) at WebKit-Devel/WebCore/rendering/DataRef.h:87
#3  0x01075238 in WebCore::SVGRenderStyle::operator== (this=0xce380fd8, o=@0xce48efd8) at WebKit-Devel/WebCore/ksvg2/css/SVGRenderStyle.cpp:90
#4  0x01459c5e in WebCore::DataRef<WebCore::SVGRenderStyle>::operator== (this=0xce37affc, o=@0xce488ffc) at WebKit-Devel/WebCore/rendering/DataRef.h:87
#5  0x011ba836 in WebCore::RenderStyle::operator== (this=0xce37afc0, o=@0xce488fc0) at WebKit-Devel/WebCore/rendering/RenderStyle.cpp:690
#6  0x0125fbd8 in WebCore::Node::diff (this=0xce2aef40, s1=0xce37afc0, s2=0xce488fc0) at WebKit-Devel/WebCore/dom/Node.cpp:647
#7  0x0126599f in WebCore::Element::recalcStyle (this=0xce2aef40, change=NoChange) at WebKit-Devel/WebCore/dom/Element.cpp:579
#8  0x01265bcb in WebCore::Element::recalcStyle (this=0xce042f2c, change=NoChange) at WebKit-Devel/WebCore/dom/Element.cpp:618
#9  0x01118ce7 in WebCore::Document::recalcStyle (this=0xcbf5a860, change=NoChange) at WebKit-Devel/WebCore/dom/Document.cpp:874
#10 0x011121e3 in WebCore::Document::updateRendering (this=0xcbf5a860) at WebKit-Devel/WebCore/dom/Document.cpp:896
#11 0x01115a1e in WebCore::Document::updateDocumentsRendering () at WebKit-Devel/WebCore/dom/Document.cpp:906
#12 0x0127a6f7 in KJS::JSAbstractEventListener::handleEvent (this=0xce112fd8, ele=0xce3b2fd8, isWindowEvent=false) at WebKit-Devel/WebCore/bindings/js/kjs_events.cpp:142
#13 0x01248020 in WebCore::EventTargetNode::handleLocalEvents (this=0xce042f2c, evt=0xce3b2fd8, useCapture=false) at WebKit-Devel/WebCore/dom/EventTargetNode.cpp:164
#14 0x012486d8 in WebCore::EventTargetNode::dispatchGenericEvent (this=0xce042f2c, e=@0xbfffe028, tempEvent=false) at WebKit-Devel/WebCore/dom/EventTargetNode.cpp:212
#15 0x01088515 in WebCore::SVGElement::sendSVGLoadEventIfPossible (this=0xce042f2c, sendParentLoadEvents=false) at WebKit-Devel/WebCore/ksvg2/svg/SVGElement.cpp:180
#16 0x0108861d in WebCore::SVGElement::closeRenderer (this=0xce042f2c) at WebKit-Devel/WebCore/ksvg2/svg/SVGElement.cpp:189
#17 0x0103c161 in WebCore::XMLTokenizer::endElementNs (this=0xcdf2af7c) at WebKit-Devel/WebCore/dom/XMLTokenizer.cpp:794
#18 0x0103c52f in WebCore::endElementNsHandler (closure=0xcdfe5e48, localname=0xcdffbc43 "svg", prefix=0x0, uri=0xcdffbc47 "http://www.w3.org/2000/svg") at WebKit-Devel/WebCore/dom/XMLTokenizer.cpp:1053

[Eric Seidel (no email)]

So the backtrace indicates that somehow an SVGRectElement has a stale SVGRenderStyle pointer.  It's not clear to me if the SVGRenderStyle pointer itself is stale, or just the associated DataRef<StyleFillData> is bad.

[Eric Seidel (no email)]

Perhaps somehow the SVGPaint object is being dereffed an extra time?

[Alexey Proskuryakov]

I cannot reproduce this anymore.

[Mark Rowe (bdash)]

No longer reproducible.