Bug 15733 - glyph-orientation-rounding-test crashes on TOT
Summary: glyph-orientation-rounding-test crashes on TOT
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore JavaScript (show other bugs)
Version: 523.x (Safari 3)
Hardware: Mac OS X 10.4
: P1 Normal
Assignee: Nobody
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2007-10-28 03:44 PDT by Eric Seidel (no email)
Modified: 2008-01-05 00:45 PST (History)
8 users (show)

See Also:


Attachments
backtrace (32.65 KB, text/plain)
2008-01-04 09:57 PST, Sam Weinig
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Seidel (no email) 2007-10-28 03:44:11 PDT
glyph-orientation-rounding-test crashes on TOT

Adam was having trouble with this test earlier today  under windows... I guess now we know why:


WARNING: Temporarily changing your system color profile from "Generic RGB Profile" to "Generic RGB Profile".
This allows the WebKit pixel-based regression tests to have consistent color values across all machines.
The colors on your screen will change for the duration of the testing.

ERROR: unable to initialize with font (null) at not known
(/Stuff/Projects/WebKit/WebCore/platform/mac/FontDataMac.mm:147 void WebCore::FontData::platformInit())
ERROR: Corrupt font detected, using (null) in place of (null) located at "not known".
(/Stuff/Projects/WebKit/WebCore/platform/mac/FontDataMac.mm:154 void WebCore::FontData::platformInit())
ERROR: failed to set up font, using system font Ä;}†
(/Stuff/Projects/WebKit/WebCore/platform/mac/FontDataMac.mm:161 void WebCore::FontData::platformInit())
ASSERTION FAILED: m_type <= CSS_DIMENSION
(/Stuff/Projects/WebKit/WebCore/css/CSSPrimitiveValue.cpp:403 double WebCore::CSSPrimitiveValue::getDoubleValue(short unsigned int))
Segmentation fault
LEAK: 2 SubresourceLoader
LEAK: 245 Node
LEAK: 2 Page
LEAK: 223 RenderObject
LEAK: 2 Frame
LEAK: 1167 KJS::Node
Comment 1 Eric Seidel (no email) 2007-11-05 12:00:56 PST
run-webkit-tests --guard --pixel svg/css/glyph-orientation-rounding-test.xhtml

crashes for me on r27439.  It does not crash w/o --pixel.
Comment 2 Eric Seidel (no email) 2007-11-05 12:02:24 PST
both --guard and --pixel are required to make it crash.  Looks like we're using free'd memory somewhere.
Comment 3 Eric Seidel (no email) 2007-11-05 12:07:06 PST
Bah!  This only seems to reproduce intermittently, even with --guard.
Comment 4 Eric Seidel (no email) 2007-11-05 12:25:27 PST
I can't seem to get a crash log out of it (even though I have my CrashLogPrefs set to "Developer").  If someone does get a crash log, please post it. :)
Comment 5 Eric Seidel (no email) 2007-11-07 02:23:02 PST
Hum.. eventually I should try running multiple copies of this test in the same DRT instance, I bet that might make it crash reliably.
Comment 6 Eric Seidel (no email) 2007-12-15 13:41:00 PST
WOW.  This turns out to be a *really* bad bug.  The problem is this generated line of code in JSCSSStyleDeclarationPrototypeFunctionGetPropertyCSSValue::callAsFunction:

    KJS::JSValue* result = toJS(exec, WTF::getPtr(imp->getPropertyCSSValue(propertyName)));

See anything wrong?

The crash is caused by the evilness that is:

    template <typename T> inline T* getPtr(const PassRefPtr<T>& p)

We're grabbing the pointer out of a PassRefPtr, but by the time it's returned, if that was the only ref to that pointer, the pointer has already been deleted (since the original PassRefPtr has gone out of scope).

This is *bad*.  Bad design.  We'll need to educate the bindings about PassRefPtrs, w/o using getPtr().

Comment 7 Eric Seidel (no email) 2007-12-15 13:53:51 PST
Hum... ap and mjs tell me this is actually a feature of C++, and that this usage of getPtr should be safe, since temporaries are guaranteed to live to the end of the expression.  Strange.
Comment 8 Mark Rowe (bdash) 2007-12-16 22:55:45 PST
<rdar://problem/5650686>
Comment 9 Alexey Proskuryakov 2007-12-17 10:46:02 PST
This crashes (actually, fails with an assertion) for me pretty reliably if I refresh this test several times in Safari. I couldn't quickly find the problem, though.

Eric - do you still need a crash log? It's pretty meaningless IMHO - clearly, we are dealing with freed memory.
Comment 10 Darin Adler 2008-01-01 21:17:20 PST
I got this crash today without --guard.
Comment 11 Sam Weinig 2008-01-04 09:56:44 PST
This assert was easily reproducible for me by running the test in the browser and repeatedly hitting refresh.
Comment 12 Sam Weinig 2008-01-04 09:57:24 PST
Created attachment 18271 [details]
backtrace
Comment 13 Darin Adler 2008-01-04 10:14:08 PST
That's an assertion failure about m_type, which probably means this is an overreleased object.
Comment 14 Sam Weinig 2008-01-05 00:45:28 PST
Fix landed in r29189.