Closed Bug 1305085 Opened 8 years ago Closed 7 years ago

sk_abort: SkTypes.h: fatal error: ""SkTFitsIn<D>(s)"" in SkScalerContext_Mac::generateMetrics

Categories

(Core :: Graphics, defect, P3)

x86_64
macOS
defect

Tracking

()

RESOLVED FIXED
mozilla56
Tracking Status
firefox52 --- wontfix
firefox-esr52 --- wontfix
firefox54 --- wontfix
firefox55 --- wontfix
firefox56 --- fixed

People

(Reporter: truber, Assigned: lsalzman)

Details

(Keywords: assertion, testcase, Whiteboard: [gfx-noted])

Attachments

(3 files)

Attached file testcase.html
Attached testcase triggers a skia abort in mozilla-central revision 60cc643978c7 (debug).

Assertion:

/builds/slave/m-cen-m64-d-000000000000000000/build/src/gfx/skia/skia/include/core/SkTypes.h:274: fatal error: ""SkTFitsIn<D>(s)""
Abort from sk_abort
Hit MOZ_CRASH() at /builds/slave/m-cen-m64-d-000000000000000000/build/src/memory/mozalloc/mozalloc_abort.cpp:33

Stacktrace:

    #0 0x60cc643978c7 in mozalloc_abort(char const*) memory/mozalloc/mozalloc_abort.cpp:33
    #1 0x60cc643978c7 in sk_abort_no_print() gfx/skia/skia/src/ports/SkMemory_mozalloc.cpp:16
    #2 0x60cc643978c7 in SkScalerContext_Mac::generateMetrics(SkGlyph*) gfx/skia/skia/include/core/SkTypes.h:274
    #3 0x60cc643978c7 in SkScalerContext::getMetrics(SkGlyph*) gfx/skia/skia/src/core/SkScalerContext.cpp:128
    #4 0x60cc643978c7 in SkGlyphCache::allocateNewGlyph(unsigned int, SkGlyphCache::MetricsType) gfx/skia/skia/src/core/SkGlyphCache.cpp:191
    #5 0x60cc643978c7 in SkGlyphCache::getGlyphIDMetrics(unsigned short, int, int) gfx/skia/skia/src/core/SkGlyphCache.cpp:168
    #6 0x60cc643978c7 in SkFindAndPlaceGlyph::GlyphIdGlyphFinder::lookupGlyphXY(char const**, int, int) gfx/skia/skia/src/core/SkFindAndPlaceGlyph.h:190
    #7 0x60cc643978c7 in SkFindAndPlaceGlyph::GlyphFindAndPlaceSubpixel<GrTextUtils::DrawBmpPosText(GrAtlasTextBlob*, int, GrBatchFontCache*, SkSurfaceProps const&, SkPaint const&, unsigned int, SkPaint::FakeGamma, SkMatrix const&, char const*, unsigned long, float const*, int, SkPoint const&)::$_1, (SkPaint::Align)0, (SkAxisAlignment)0>::findAndPositionGlyph(char const**, SkPoint, (GrTextUtils::DrawBmpPosText&&)(GrAtlasTextBlob*, int, GrBatchFontCache*, SkSurfaceProps const&, SkPaint const&, unsigned int, SkPaint::FakeGamma, SkMatrix const&, char const*, unsigned long, float const*, int, SkPoint const&)::$_1) gfx/skia/skia/src/core/SkFindAndPlaceGlyph.h:461
    #8 0x60cc643978c7 in GrTextUtils::DrawBmpPosText(GrAtlasTextBlob*, int, GrBatchFontCache*, SkSurfaceProps const&, SkPaint const&, unsigned int, SkPaint::FakeGamma, SkMatrix const&, char const*, unsigned long, float const*, int, SkPoint const&) gfx/skia/skia/src/core/SkFindAndPlaceGlyph.h:685
    #9 0x60cc643978c7 in GrAtlasTextContext::CreateDrawPosTextBlob(GrTextBlobCache*, GrBatchFontCache*, GrShaderCaps const&, GrPaint const&, SkPaint const&, SkPaint::FakeGamma, SkMatrix const&, SkSurfaceProps const&, char const*, unsigned long, float const*, int, SkPoint const&) gfx/skia/skia/src/gpu/text/GrAtlasTextContext.cpp:310
    #10 0x60cc643978c7 in GrAtlasTextContext::drawPosText(GrContext*, GrDrawContext*, GrClip const&, GrPaint const&, SkPaint const&, SkMatrix const&, SkSurfaceProps const&, char const*, unsigned long, float const*, int, SkPoint const&, SkIRect const&) gfx/skia/skia/src/gpu/text/GrAtlasTextContext.cpp:358
Attached file log.txt
his one looks Mac-only, so can only repro there. Mason, can you take a look?
Flags: needinfo?(mchang)
Priority: -- → P3
Whiteboard: [gfx-noted]
Assignee: nobody → mchang
Flags: needinfo?(mchang)
Mass wontfix for bugs affecting firefox 52.
This still pop's up.
SkScalerContext_Mac uses SkScalerContext::computeMatrices to factor out the rotation from the transform. This particular transform, while valid, once the rotation is factored out, has a 0 for it's Y scale. When this is later inverted to produce the output matrices, it fills the matrix with infs and nans. This causes problems downwind.

The Windows font hosts already check if the Y scale is 0, and if so, just set it to 1, so is otherwise immune to this. So it makes sense to just fix this centrally at the source of the problem, and never generate 0 for the scale in the first place. This way, all font hosts can proceed happily.
Assignee: mchang → lsalzman
Status: NEW → ASSIGNED
Attachment #8877707 - Flags: review?(mchang)
Attachment #8877707 - Flags: review?(mchang) → review+
Pushed by lsalzman@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a0a703ef8e42
don't let SkScalerContext::computeMatrices generate zero scales. r=mchang
https://hg.mozilla.org/mozilla-central/rev/a0a703ef8e42
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla56
Is there any reason to consider this for backport to 55 or can it ride the trains?
Flags: needinfo?(lsalzman)
(In reply to Ryan VanderMeulen [:RyanVM] from comment #9)
> Is there any reason to consider this for backport to 55 or can it ride the
> trains?

The only real consequence of this should be the assertion in debug mode, which this fixes. But otherwise, in release builds, text will just fail to show up regardless. So I think this is safe to just let ride the trains.
Flags: needinfo?(lsalzman)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: