Apache OpenOffice (AOO) Bugzilla – Issue 99081
During glyph fallback we seem to release a font from the fontcache, but then use it again
Last modified: 2009-03-11 11:13:36 UTC
i.e. in this attached .ppt. valgrind has... ==23673== Invalid read of size 4 ==23673== at 0x4B38197: ImplFontEntry::GetFallbackForUnicode(unsigned long, String*) const (outdev3.cxx:1542) ==23673== by 0x4B2D0E3: ImplDevFontList::GetGlyphFallbackFont(ImplFontSelectData&, rtl::OUString&, int) const (outdev3.cxx:1975) ==23673== by 0x4B2D589: ImplFontCache::GetGlyphFallbackFont(ImplDevFontList*, ImplFontSelectData&, int, rtl::OUString&) (outdev3.cxx:3214) ==23673== by 0x4B2D781: OutputDevice::ImplGlyphFallbackLayout(SalLayout*, ImplLayoutArgs&) const (outdev3.cxx:6280) ==23673== by 0x4B2F6F9: OutputDevice::ImplLayout(String const&, unsigned short, unsigned short, Point const&, long, long const*, bool) const (outdev3.cxx:6216) ==23673== by 0x4B2FC18: OutputDevice::GetTextArray(String const&, long*, unsigned short, unsigned short) const (outdev3.cxx:5882) ==23673== by 0x4B2FD0A: OutputDevice::GetTextWidth(String const&, unsigned short, unsigned short) const (outdev3.cxx:5816) ==23673== by 0x4853213: WinMtfOutput::DrawText(Point&, String&, long*, unsigned char, long) (winmtf.cxx:1567) ==23673== by 0x4859B89: WMFReader::ReadRecordParams(unsigned short) (winwmf.cxx:486) ==23673== by 0x485B1F3: WMFReader::ReadWMF() (winwmf.cxx:1065) ==23673== by 0x485090A: ConvertWMFToGDIMetaFile(SvStream&, GDIMetaFile&, FilterConfigItem*) (wmf.cxx:57) ==23673== by 0x480DA05: GraphicFilter::ImportGraphic(Graphic&, String const&, SvStream&, unsigned short, unsigned short*, unsigned long, com::sun::star::uno::Sequence<com::sun::star::beans::PropertyValue>*) (filter.cxx:1486) ==23673== Address 0x99488f4 is 260 bytes inside a block of size 268 free'd ==23673== at 0x400590A: free (vg_replace_malloc.c:323) ==23673== by 0x4030374: rtl_freeMemory (alloc_global.c:317) ==23673== by 0x8048D27: operator delete(void*) (in /usr/lib/openoffice.org3/program/soffice.bin) ==23673== by 0x4C846EE: ImplServerFontEntry::~ImplServerFontEntry() (glyphcache.cxx:503) ==23673== by 0x4B25976: ImplFontCache::Release(ImplFontEntry*) (outdev3.cxx:3252) ==23673== by 0x4B2D8CB: OutputDevice::ImplGlyphFallbackLayout(SalLayout*, ImplLayoutArgs&) const (outdev3.cxx:6327) ==23673== by 0x4B2F6F9: OutputDevice::ImplLayout(String const&, unsigned short, unsigned short, Point const&, long, long const*, bool) const (outdev3.cxx:6216) ==23673== by 0x4B2FC18: OutputDevice::GetTextArray(String const&, long*, unsigned short, unsigned short) const (outdev3.cxx:5882) ==23673== by 0x4B2FD0A: OutputDevice::GetTextWidth(String const&, unsigned short, unsigned short) const (outdev3.cxx:5816) ==23673== by 0x4853213: WinMtfOutput::DrawText(Point&, String&, long*, unsigned char, long) (winmtf.cxx:1567) ==23673== by 0x4859B89: WMFReader::ReadRecordParams(unsigned short) (winwmf.cxx:486) ==23673== by 0x485B1F3: WMFReader::ReadWMF() (winwmf.cxx:1065) It looks simply that we have... for ... { ImplFontEntry* pFallbackFont = mpFontCache->GetGlyphFallbackFont( mpFontList, aFontSelData, nFallbackLevel-nDevSpecificFallback, aMissingCodes ); //pFallbackFont has now e.g. refcount of 1 ... aFontSelData.mpFontEntry = pFallbackFont; ... mpFontCache->Release( pFallbackFont ); //pFallbackFont has been deleted, i.e. aFontSelData.mpFontEntry is invalid, //but on the next cycle GetGlyphFallbackFont accesses that //aFontSelData.mpFontEntry }
Created attachment 60070 [details] sample input
Created attachment 60071 [details] plausible patch
Good catch! I have some crashreports that can be explained by that.
*** Issue 86845 has been marked as a duplicate of this issue. ***
*** Issue 91087 has been marked as a duplicate of this issue. ***
> This is probably more likely to be seen with the system allocator, and may be > more likely to happen on system stl. Yes, that could explain a lot. I had a closer look at problem. It only happens when fontconfig-assisted glyph-fallback is active, so the crashreports I mentioned above, which are mostly from WIN, can not be explained by it. There is also another way to solve the problem with the early release: By resetting the font selector request to base level before requesting yet another fallback font. I'll attach a mini-patch below. The alternate approach has the potential benefit that fontconfig could suggest a better stylistic match to the base-level font which has missing glyphs. There would be a potential performance penalty though: We cache the expensive (e.g. #i97544#) fontconfig replies in a FontEntry. Currently in the fallback's FontEntry, with the alternate approach in the base-level entry. Since a glyph fallback font has a much high probability to be in the fallback chain again the cache hit rate would go down quite a bit.
Created attachment 60117 [details] request fallback suggestion for base-level font instead of level-1 font
@cmc: regarding the bugdoc foo.odp I suspect there is an import problem. What else would the U+FFB1 (halfwidth hangul letter mieum) and U+FFB6 (halfwidth hangul letter ssangsios) be good for in english page about wave propagation?
@sba/@cmc: please verify in CWS gfbcrash
Was fixed in CWS gfbcrash.
looks good from my side at least, valgrind is agreeably silent
SBA: I can see no difference in behavior in CWS with this document and "stressed font usage". Good. Set to "verified" according to CMCs comment.
closing, in OOO310_m4 and DEV300_m43