Bug 21183
Summary: | REGRESSION: Reproducible crash running svg/dynamic-updates/SVGCursorElement-svgdom-x-prop.html | ||
---|---|---|---|
Product: | WebKit | Reporter: | Mark Rowe (bdash) <mrowe> |
Component: | SVG | Assignee: | 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 |
Mark Rowe (bdash)
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
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Mark Rowe (bdash)
This needs fixed ASAP in order to get the buildbots back to green.
Alexey Proskuryakov
See also bug 19762, which might have the same root cause.
Mark Rowe (bdash)
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.
Alexey Proskuryakov
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.
Nikolas Zimmermann
(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.
Eric Seidel (no email)
*** This bug has been marked as a duplicate of 19762 ***