WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
20339
REGRESSION(
r35531
-
r35615
): Acid3 crashes on Windows in CachedFont::getSVGFontById
https://bugs.webkit.org/show_bug.cgi?id=20339
Summary
REGRESSION(r35531-r35615): Acid3 crashes on Windows in CachedFont::getSVGFont...
mhstamate
Reported
2008-08-09 05:28:20 PDT
Tested on: - Windows XP SP2 - Apple Safari for Windows 3.1.2 using a WebKit nightly build for Windows from
http://nightly.webkit.org/
- Intel P4 2.4 GHz CPU (single core) - javascript is enabled How often it happens: always Description: 1. using any nightly WebKit build from nightly.webkit.org after build
r35531
(the first one avaliable on that website is
r35615
) 2. go to
http://acid3.acidtests.org/
to take the Acid3 test 3. the test runs, it displays 74/100 and then the web browser crashes The last WebKit nightly build for Windows on nightly.webkit.org that doesn't crash is
r35531
. The next WebKit nightly build for Windows on nightly.webkit.org is
r35615
, and it does crash. Every WebKit nightly build following
r35531
that was tested caused a crash (
r35615
, 35641, 35648). So, the change that caused the hang must have happened somewhere in between builds
r35531
and
r35615
(for Windows).
Attachments
Use explicit namespaces in *ElementFactory files
(1.35 KB, patch)
2008-08-09 18:20 PDT
,
mitz
no flags
Details
Formatted Diff
Diff
Use explicit namespaces in *ElementFactory files
(1.97 KB, patch)
2008-08-10 19:25 PDT
,
mitz
eric
: review+
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Matt Lilek
Comment 1
2008-08-09 11:13:39 PDT
Confirmed with
r35646
. I get the following assertion failure: ASSERTION FAILED: node->hasTagName(SVGNames::fontTag) (..\loader\CachedFont.cpp:167 WebCore::CachedFont::getSVGFontById)
> WebKit.dll!WebCore::CachedFont::getSVGFontById(const WebCore::String & fontName={...}) Line 167 + 0x30 bytes C++
WebKit.dll!WebCore::CSSFontFaceSource::getFontData(const WebCore::FontDescription & fontDescription={...}, bool syntheticBold=false, bool syntheticItalic=false, WebCore::CSSFontSelector * fontSelector=0x05a949c0) Line 131 + 0x24 bytes C++ WebKit.dll!WebCore::CSSFontFace::getFontData(const WebCore::FontDescription & fontDescription={...}, bool syntheticBold=false, bool syntheticItalic=false) Line 97 + 0x26 bytes C++ WebKit.dll!WebCore::CSSSegmentedFontFace::getFontData(const WebCore::FontDescription & fontDescription={...}) Line 114 + 0x29 bytes C++ WebKit.dll!WebCore::CSSFontSelector::getFontData(const WebCore::FontDescription & fontDescription={...}, const WebCore::AtomicString & familyName={...}) Line 532 + 0x13 bytes C++ WebKit.dll!WebCore::FontCache::getFontData(const WebCore::Font & font={...}, int & familyIndex=1, WebCore::FontSelector * fontSelector=0x05a949c0) Line 334 + 0x21 bytes C++ WebKit.dll!WebCore::FontFallbackList::fontDataAt(const WebCore::Font * font=0x05ecbdf8, unsigned int realizedFontIndex=0) Line 100 + 0x1c bytes C++ WebKit.dll!WebCore::FontFallbackList::primaryFont(const WebCore::Font * f=0x05ecbdf8) Line 60 + 0x1c bytes C++ WebKit.dll!WebCore::FontFallbackList::determinePitch(const WebCore::Font * font=0x05ecbdf8) Line 71 + 0xc bytes C++ WebKit.dll!WebCore::FontFallbackList::isFixedPitch(const WebCore::Font * f=0x05ecbdf8) Line 49 + 0x23 bytes C++ WebKit.dll!WebCore::Font::isFixedPitch() Line 553 C++ WebKit.dll!WebCore::RenderText::widthFromCache(const WebCore::Font & f={...}, int start=0, int len=1, int xPos=0) Line 368 + 0x8 bytes C++ WebKit.dll!WebCore::RenderText::calcPrefWidths(int leadWidth=0) Line 602 + 0x1b bytes C++ WebKit.dll!WebCore::RenderText::maxPrefWidth() Line 500 + 0x14 bytes C++ WebKit.dll!WebCore::RenderText::width(unsigned int from=0, unsigned int len=1, const WebCore::Font & f={...}, int xPos=0) Line 1016 + 0x12 bytes C++ WebKit.dll!WebCore::RenderBlock::findNextLineBreak(WebCore::BidiResolver<WebCore::InlineIterator,WebCore::BidiRun> & resolver={...}, WebCore::EClear * clear=0x0025f034) Line 1985 + 0x31 bytes C++ WebKit.dll!WebCore::RenderBlock::layoutInlineChildren(bool relayoutChildren=false, int & repaintTop=0, int & repaintBottom=0) Line 934 + 0x1d bytes C++ WebKit.dll!WebCore::RenderBlock::layoutBlock(bool relayoutChildren=false) Line 626 C++ WebKit.dll!WebCore::RenderBlock::layout() Line 536 + 0x14 bytes C++ WebKit.dll!WebCore::RenderSVGText::layout() Line 105 C++ WebKit.dll!WebCore::RenderObject::layoutIfNeeded() Line 507 + 0x30 bytes C++ WebKit.dll!WebCore::RenderSVGRoot::layout() Line 106 C++ WebKit.dll!WebCore::RenderBlock::layoutBlockChildren(bool relayoutChildren=false, int & maxFloatBottom=0) Line 1281 + 0x12 bytes C++ WebKit.dll!WebCore::RenderBlock::layoutBlock(bool relayoutChildren=false) Line 630 C++ WebKit.dll!WebCore::RenderBlock::layout() Line 536 + 0x14 bytes C++ WebKit.dll!WebCore::RenderView::layout() Line 121 C++ WebKit.dll!WebCore::FrameView::layout(bool allowSubtree=true) Line 483 + 0x12 bytes C++
mitz
Comment 2
2008-08-09 17:49:10 PDT
The assertion fails because SVGElementFactory.cpp uses the HTMLNames namespace for the tag names instead of the SVGNames namespace. That probably happens because an earlier file in DerivedSources.cpp includes a "using namespace WebCore::HTMLNames" statement. I fixed the problem for *ElementFactory.cpp, only to get another crash on Acid3, so this should probably be fixed in DerivedSources.cpp.
mitz
Comment 3
2008-08-09 18:20:34 PDT
Created
attachment 22720
[details]
Use explicit namespaces in *ElementFactory files
mitz
Comment 4
2008-08-10 19:25:47 PDT
Created
attachment 22723
[details]
Use explicit namespaces in *ElementFactory files Turns out the other crash was a separate issue, fixed in
r35660
.
Eric Seidel (no email)
Comment 5
2008-08-10 19:51:23 PDT
Comment on
attachment 22723
[details]
Use explicit namespaces in *ElementFactory files Looks good.
mitz
Comment 6
2008-08-10 21:52:33 PDT
Fixed in <
http://trac.webkit.org/changeset/35661
>.
mhstamate
Comment 7
2008-08-10 23:46:22 PDT
The crash no longer happens here either.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug