Description: When opening a document in Writer that uses a specific TTF font the program crashes with a "Fatal Error - Bad Allocation" message. The document was created with early versions of LibreOffice using that same font file, so the font file worked fine in the past. This crash also appears if you open a new empty document and try to select the font (scrolling the font list with "Font preview" activated. First detected with 5.3.4.X (Win64), now I have installed 5.4.0.3 (Win64) and the bug persists. I think this is the same bug as #106265 (which is marked as solved in 5.4) Steps to Reproduce: 1. Install the attached TTF font 2.a Open a document with that font OR 2.b Open a new empty document, scroll down to the font (FadingSunsIcons) with the option "Font preview" activated Actual Results: Program crashes with "Fatal Error - Bad Allocation" message. Expected Results: No crash :) Reproducible: Always User Profile Reset: Yes, also happens in Safe Mode Additional Info: Adding the font file that provokes the crash User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Created attachment 135966 [details] Font file that causes the crash
Confirming on Windows 10 Pro 64-bit en-US with Version: 5.4.1.2 (x64) Build ID: ea7cb86e6eeb2bf3a5af73a8f7777ac570321527 CPU threads: 8; OS: Windows 6.19; UI render: GL; Locale: en-US (en_US); Calc: group and on recent master Version: 6.0.0.0.alpha0+ Build ID: 9d4fc496d498f2f5c7fedba94f656ef3189b85dd CPU threads: 8; OS: Windows 6.19; UI render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2017-09-02_23:59:12 Locale: en-US (en_US); Calc: CL It is not linked to the FontPreview droplist--bug 106265, there is no movement of GDI count. And Tools -> Options -> View: unchecking "Show preview of fonts" has no effect on the immediate "Bad allocation" crash. Likewise, the Sidebar Properties -> Character content panel drop list, the Special Character dialog, and the Character dialog Font tab preview all will crash LO when the font is selected. So no GDI overflow. Rather, the font itself seems to be rather badly broken. Suspect there is some invalid/illegal Unicode mapping. In fact, if I use FontCreator and export the font into a PUA Symbol font it is handled without issue in all locations of the UI. Unclear the origin of the font, but it seems to be a MS Symbol encoded font that was converted to Unicode--just badly. Would say NOTOURBUG, but the crash here is a little disconcerting, seems we should be more graceful about it. Also, this Windows crash is not kicking off the mini-dump needed for crashreport. Khaled, Chris? Markus--fyi on this crash not triggering the minidump/crashreport.
Created attachment 135978 [details] x86 WinDbg stack trace of TB39 2017-09-02 build of master
(In reply to V Stuart Foote from comment #3) > Created attachment 135978 [details] > x86 WinDbg stack trace of TB39 2017-09-02 build of master STR used for attached stack trace 1. Install the attached font to Windows 2. restart LibreOffice 3. on Standard toolbar font droplist scroll the fontlist 4a. crash as the entry for FadingSunsIcons scrolls into view with preview -or- 4b. with previews set off, immediate crash on selecting the FadingSunsIcons 5. error "bad allocation" Other steps to crash by selecting the font from the Special Character dialog, or from the Character Dialog -> Font tab's Font droplist, or from the Sidebar Properties deck, Characters content panel.
Caolán: since it concerns vcl, thought you might be interested in this one. Could someone gives his/her opinion about this patch here: https://gerrit.libreoffice.org/#/c/41860/ ? I couldn't test it since I don't use Windows for LO dev.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3b7c4d3ec6edb5db774d5352222b77239175f96 tdf#112180: avoid crash with specific ttf It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Don't hesitate to provide some feedback with a daily build which includes the patch. If it's ok, I'll backport it on 5.4 branch. Since I'm not sure it fixes the crash, I'll let to ASSIGNED status for the moment.
I filed bug #109253, similar to this bug. I just received the email regarding this bug (#112180). Then I slowly scrolled through my font list using the up/down arrows on the scroll bar. When it got to “Helvetica Narrow” LO crashed. I tried it again, same result. At the point when it was crashing, all other font names in the drop-down list disappeared, leaving just "Helvetica Narrow" visible for a brief period until the crash process completed. Perhaps a deliberate code feature ("This is the font!"). Then I used the Windows 10 font manager to look for that font. There was a “Helvetica” folder with lots of variations of Helvetica in it, but there was also an individual font icon next to the “Helvetica” folder with the name “Helvetica Narrow S Regular”. I deleted that font with Windows font manager. I restarted LO. Scrolling through the drop-down font list at any speed no longer causes a crash. So, my problem seems to be solved by finding a troublesome font and deleting it, as Telesto mentioned in the discussions of the bug that I filed. I did not see any correlation of a specific font until now. Apparently I never did a slow-scroll through the “Helvetica Narrow” part of the font list using the scroll-bar arrows until now. However, there is still some strangeness going on with Helvetica fonts (the short story being, I need to clean up my Helvetica fonts). I still have 4 entries in the drop-down font list: Helvetica Helvetica Narrow Helvetical-Narrow Helvetica Narrow S Opening the “Helvetica” font folder reveals 13 variations of Helvetica, including some duplicates. Here is each font name as described in the Helvetica folder, followed by the file name and it's source, assuming the data is accurate: Helvetica Bold [helvetica-bold.otf File version 001.003 Lexmark] Helvetica Bold Italic [helvetica-bolditalic.otf File version 001.003 Lexmark] Helvetica Bold Narrow Oblique [helvetica-narrow-boldoblique.otf File version OTF1.0.PS 003.000;Core 1.0.22 Copyright (c) 1985, 1987, 1989, 1990, 1997, 1998 Adobe Systems Incorporated.] Helvetica Bold Narrow Oblique [Duplicate of above item, same data, only one font file] Helvetica Medium [helvetica.otf File version 001.003 Lexmark] Helvetica Medium Italic [helvetica-italic.otf File version 001.003 Lexmark] Helvetica Narrow [unicode.helvetin.ttf” File version 1.0] Helvetica Narrow [Duplicate of above item, same data, only one font file] Helvetica Narrow Bold [helvetica-narrow-bold_0.otf File version 001.003 Lexmark] Helvetica Narrow Bold Italic [helvetica-narrow-bolditalic_0.otf File version 001.003 Lexmark] Helvetica Narrow Medium Italic [helvetica-narrow-italic_0.otf File version 001.003 Lexmark] Helvetica Narrow Oblique [helvetica-narrow-oblique.otf File version OTF1.0.PS 003.000;Core 1.0.22 Copyright (c) 1985, 1987, 1989, 1990, 1997, 1998 Adobe Systems Incorporated.] Helvetica Narrow Oblique [Duplicate of above, same data, only one file] I had to look in the actual font file to get the “...Adobe Systems...” details from those 2 fonts. Each font is represented in the Helvetica folder by an icon with “Abg” displayed on it, with those 3 characters displayed in that font variation. However, the 2 icons representing the 2 versions of “Helvetica Narrow”, as well as the overall Helvetica folder, appear to have 2 (not 3) Chinese characters on them. Sorry, I don’t really know if it is Chinese or some other font, but it is not English. The “Properties” for those two “Helvetica Narrow” ttf fonts look sketchy, with the bare minimum of information. Some fonts appear to be from Adobe, others from Lexmark, and two that are of unknown origin, if the detail information is correct. Further oddities: When I select “Helvetica Narrow” it appears as a light italic font when typed in a document. The font name as it appears in the font drop-down list looks like a condensed, bold, non-italic font. Also, the word “name” looks like “nam e” with much too large a space between the “m” and the “e”. So there are spacing issues. “Helvetica Narrow S” appears as a light monospace font when typed in a document, and in the drop-down list. In fact, it looks absolutely IDENTICAL to “Courier New”. So something strange is going on there. Helvetica-Narrow: Same results as “Helvetica Narrow”. I removed the duplicate font Helvetica Narrow (“unicode.helvetin.ttf”) from the Helvetica folder. This caused the Helvetica folder to return to 3 English characters “Abg” displayed on the folder. I still have “Helvetica”, “Helvetica-Narrow” and “Helvetica Narrow” in the drop-down font list. There are other oddities, but it seems likely that I need to remove all of my Helvetica fonts and install known-good ones.
Created attachment 136010 [details] WinDbg x86 crash Character dialog on selection of bad font @Julien, * Not sure that corrects things fully. Attached WinDbg x86 for today's TB39 with patch, caught on crash in font preview for the Character dialog on selection of the troubled font. Was not able yet to catch the fault in the toolbar, sidebar or special character dialog--kept going past it and catching trace of the ShowNativeMessageBox alert. Will move to another system and see if I can catch a ST of the faulting calls there.
(In reply to JohnHardy from comment #8) > I filed bug #109253, similar to this bug. > Installing attachment 136000 [details] "HelveticaNarrowSRegular.ttf" from bug 109253 a font preview of this font results identical stack trace (via the Character dialog) to that of attachment 135966 [details] here. 0161c088 681b3047 vcllo!std::vector<unsigned char,std::allocator<unsigned char> >::vector<unsigned char,std::allocator<unsigned char> ><unsigned char const *,void>(unsigned char * _First = 0x00000000 "", unsigned char * _Last = 0xffffffff "--- memory read error at address 0xffffffff ---")+0x1f [c:\program files (x86)\microsoft visual studio 14.0\vc\include\vector @ 779] 12 0161c2e0 67e136d3 vcllo!WinSalGraphics::GetFontMetric(class tools::SvRef<ImplFontMetricData> * rxFontMetric = 0x1af108c0, int nFallbackLevel = 0n0)+0x3d7 [c:\cygwin\home\tinderbox\master\vcl\win\gdi\salfont.cxx @ 987] 13 0161c4b8 67e11050 vcllo!OutputDevice::ImplNewFont(void)+0x433 [c:\cygwin\home\tinderbox\master\vcl\source\outdev\font.cxx @ 1093] 14 0161c5a8 67e10f8f vcllo!OutputDevice::GetFontMetric(void)+0x60 [c:\cygwin\home\tinderbox\master\vcl\source\outdev\font.cxx @ 171] 15 0161c5e0 6b246ba1 vcllo!OutputDevice::GetFontMetric(class vcl::Font * rFont = 0x0c118650)+0x5f [c:\cygwin\home\tinderbox\master\vcl\source\outdev\font.cxx @ 223] 16 0161c614 6b24380d svxlo!`anonymous namespace'::scaleFontWidth(class vcl::Font * rFont = 0x0c118650, class OutputDevice * rRenderContext = 0x12031140, long * n100PercentFont = 0x0c1186dc)+0x41 [c:\cygwin\home\tinderbox\master\svx\source\dialog\fntctrl.cxx @ 90] 17 0161c62c 6b242f8b svxlo!FontPrevWin_Impl::ScaleFontWidth(class OutputDevice * rOutDev = 0x12031140)+0x2d [c:\cygwin\home\tinderbox\master\svx\source\dialog\fntctrl.cxx @ 442] 18 0161c850 67b9f883 svxlo!SvxFontPrevWindow::Paint(class OutputDevice * rRenderContext = 0x12031140, class tools::Rectangle * __formal = 0x0161caf0)+0x95b [c:\cygwin\home\tinderbox\master\svx\source\dialog\fntctrl.cxx @ 709] 19 0161cac8 67ba0da6 vcllo!PaintHelper::DoPaint(class vcl::Region * pRegion = 0x00000000)+0x563 [c:\cygwin\home\tinderbox\master\vcl\source\window\paint.cxx @ 303]
Thank you V Stuart Foote, it seems the patch isn't wrong but I must keep on by finding a way to deal with empty aHheaRawData or empty aOS2RawData.
I had tried with https://gerrit.libreoffice.org/#/c/41914/3 but it seems wrong way. Sorry, I can't help here.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=f263692de96ac68e73eeb953b7e92a18d149f30e Resolves: tdf#112180: avoid crash with specific ttf It will be available in 6.0.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-4": http://cgit.freedesktop.org/libreoffice/core/commit/?id=45bc0b931eb2569bf267d226b67e58b7b8390529&h=libreoffice-5-4 Resolves: tdf#112180: avoid crash with specific ttf It will be available in 5.4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 109253 has been marked as a duplicate of this bug. ***
*** Bug 111347 has been marked as a duplicate of this bug. ***
*** Bug 111885 has been marked as a duplicate of this bug. ***
*** Bug 112506 has been marked as a duplicate of this bug. ***
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-5-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=70f8b4b9b0330b9150c5d6c3f066834f20023578&h=libreoffice-5-3 Resolves: tdf#112180: avoid crash with specific ttf It will be available in 5.3.7. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 112941 has been marked as a duplicate of this bug. ***