Hard to tell exactly what's wrong; it seems to be within the
IDWriteTextLayout::Draw call, so somewhere inside DWrite rather than in Firefox code.
I don't think the
fallbackLayout itself can be NULL, as I'd expect that to result in a READ access of a pointer value slightly > 0, not a WRITE access at slightly < 0. And we error-check the result of the
I guess if the
mFallbackRenderer is broken, that could be a cause; maybe the
aFactory->GetSystemFontCollection call in the
DWriteFontFallbackRenderer constructor failed? We have a (debug) assertion there, but in a release build we'd proceed with a null
mSystemFonts, which sounds bad.
Or the breakage could be deeper inside DWrite, maybe related to a failure with a specific font that it tries to use; an i/o error accessing the font file might cause something like this.
Maybe we should just wrap the body of
gfxDWriteFontList::PlatformGlobalFontFallback in an exception handler, so that any sort of internal DWrite failure in there doesn't crash the whole process. We can safely return NULL on any kind of exception, and let the rest of gecko deal with the failure to find a suitable font; that's not a fatal problem.