Bug 21183

Summary: REGRESSION: Reproducible crash running svg/dynamic-updates/SVGCursorElement-svgdom-x-prop.html
Product: WebKit Reporter: Mark Rowe (bdash) <mrowe>
Component: SVGAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: ap, eric, mrowe, rwlbuis, zimmermann
Priority: P1 Keywords: NeedsReduction, Regression
Version: 528+ (Nightly build)   
Hardware: Mac   
OS: OS X 10.5   

Description Mark Rowe (bdash) 2008-09-27 15:16:14 PDT
The buildbots at build.webkit.org frequently report a crash in svg/dynamic-updates/SVGCursorElement-svgdom-x-prop.html while running the layout tests.  I am able to reproduce this crash 100% of the time locally if I run DumpRenderTree under guard malloc:

$ gdb --args ./WebKitBuild/Debug/DumpRenderTree LayoutTests/svg/dynamic-updates/SVGCursorElement-svgdom-x-prop.html
(gdb) set env DYLD_INSERT_LIBRARIES=/usr/lib/libgmalloc.dylib
(gdb) r
...
...
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xd0650f24
0x036f4196 in WebCore::QualifiedName::matches (this=0xd0650f24, other=@0x4a2a65c) at dom/QualifiedName.h:63
63	    bool matches(const QualifiedName& other) const { return m_impl == other.m_impl || (localName() == other.localName() && namespaceURI() == other.namespaceURI()); }
(gdb) bt 15
#0  0x036f4196 in WebCore::QualifiedName::matches (this=0xd0650f24, other=@0x4a2a65c) at dom/QualifiedName.h:63
#1  0x03663897 in WebCore::Element::hasTagName (this=0xd0650ef0, tagName=@0x4a2a65c) at dom/Element.h:98
#2  0x03689e50 in resourceReferencedByCursorElement (fragmentId=@0xbfffeb44, document=0xc9c0b860) at WebCore/css/CSSCursorImageValue.cpp:48
#3  0x0368a4e1 in WebCore::CSSCursorImageValue::~CSSCursorImageValue (this=0xd0748fb0) at WebCore/css/CSSCursorImageValue.cpp:73
#4  0x03c3783d in WTF::RefCounted<WebCore::StyleBase>::deref (this=0xd0748fb4) at RefCounted.h:96
#5  0x036851fe in WTF::RefPtr<WebCore::CSSValue>::~RefPtr (this=0xd074afc0) at RefPtr.h:50
#6  0x03685211 in WTF::RefPtr<WebCore::CSSValue>::~RefPtr (this=0xd074afc0) at RefPtr.h:50
#7  0x036a841b in WTF::VectorDestructor<true, WTF::RefPtr<WebCore::CSSValue> >::destruct (begin=0xd074afc0, end=0xd074afc4) at Vector.h:80
#8  0x036a8444 in WTF::VectorTypeOperations<WTF::RefPtr<WebCore::CSSValue> >::destruct (begin=0xd074afc0, end=0xd074afc4) at Vector.h:235
#9  0x036a84c2 in WTF::Vector<WTF::RefPtr<WebCore::CSSValue>, 0ul>::shrink (this=0xd071afe4, size=0) at Vector.h:694
#10 0x036a84f4 in WTF::Vector<WTF::RefPtr<WebCore::CSSValue>, 0ul>::clear (this=0xd071afe4) at Vector.h:496
#11 0x036a8507 in WTF::Vector<WTF::RefPtr<WebCore::CSSValue>, 0ul>::~Vector (this=0xd071afe4) at Vector.h:445
#12 0x036a8529 in WTF::Vector<WTF::RefPtr<WebCore::CSSValue>, 0ul>::~Vector (this=0xd071afe4) at Vector.h:445
#13 0x03712451 in WebCore::CSSValueList::~CSSValueList (this=0xd071afd0) at WebCore/css/CSSValueList.cpp:49
#14 0x03c3783d in WTF::RefCounted<WebCore::StyleBase>::deref (this=0xd071afd4) at RefCounted.h:96
Comment 1 Mark Rowe (bdash) 2008-09-27 15:16:36 PDT
This needs fixed ASAP in order to get the buildbots back to green.
Comment 2 Alexey Proskuryakov 2008-09-27 17:20:50 PDT
See also bug 19762, which might have the same root cause.
Comment 3 Mark Rowe (bdash) 2008-09-27 17:28:01 PDT
It does look similar.  I think we need to address the underlying issue rather than just disabling tests and pretending that it does not exist.
Comment 4 Alexey Proskuryakov 2008-09-28 00:31:00 PDT
Point not taken - since this issue results in semi-random crashes, sometimes in subsequent unrelated tests, I think that disabling the offending tests is necessary, too.

Dropping support for SVGCursorElement may be another option, if no one is interested in fixing it.
Comment 5 Nikolas Zimmermann 2008-09-28 08:00:49 PDT
(In reply to comment #4)
> Point not taken - since this issue results in semi-random crashes, sometimes in
> subsequent unrelated tests, I think that disabling the offending tests is
> necessary, too.
> 
> Dropping support for SVGCursorElement may be another option, if no one is
> interested in fixing it.

I'd rather suggest: disable this test for now, and I'll have a look at it next week.
Eric was also interested in fixing  IIRC.
Comment 6 Eric Seidel (no email) 2008-10-07 16:39:37 PDT

*** This bug has been marked as a duplicate of 19762 ***