On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ (x64) Build ID: 042f16a19e3d5f884759dae71264433b988df0e6 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86_64@62-TDF, Branch:MASTER, Time: 2016-03-16_10:03:38 Locale: en-US (en_US) Symbola font has been installed. With the new DirectWrite implementation for OpenGL if the Tools -> Options -> View: Font Lists "Show preview of fonts" is checked active when OpenGL rendering is enabled, scrolling the combobox list of fonts crashes on reaching the Symbola entry. On deselecting the font preview and restarting, able to pick Symbola without issue.
Not sure why especially Symbola preview is affected, suspect maybe it is encoded differently than other TTF. Or, it could be that the preview will always crash, and it just seems to be when I reach the Symbola entry on the list.
Created attachment 123642 [details] WinDbg 32 stack trace of crash in dwrite when font preview enabled @Tor, Tim Catch this trace pointing to crash in dwrite from TB39 32-bit build, but same behavior on 64-bit TB62 build (just no symbols to work against there). Seems to hang on scrolling just as I get to Symbola on the combobox font list when preview is enabled. Does not crash when font preview is disabled.
What is this "Symbola" font? I find at least two apparently different fonts with that name (https://zhm.github.io/symbola/ and http://users.teilar.gr/~g1951d/ )
Created attachment 123643 [details] font info for Symbola Sorry, talking about the more common Symbola public domain font by George Douros and the Unicode Fonts for Ancient Scripts project. updates for Unicode 8.0, covering 7,890 codepoints http://users.teilar.gr/~g1951d/Symbola.zip SMP codepoint coverage similar to MS Segoe UI Symbol so useful cross platform.
--Linux packaging providing main source of Unicode 7.0 SMP Emoji-- Ubuntu -> ttf-ancient-fonts openSUSE -> gdouros-symbola-fonts Fedora/RHEL -> gdouros-symbola-fonts
On Windows 10 Pro 64-bit en-US with Symbola TTF Version: 5.2.0.0.alpha0+ Build ID: 1d5767c6e464b914812867aac5c3ccd0745dd1ea CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@42, Branch:master, Time: 2016-03-20_00:02:24 Locale: en-US (en_US) Crash in Writer focus in the Formatting toolbar, scroll the font name combobox dropdown list past the entry for Symbola
I guess we'd have to catch the exception and recover somehow. I wonder though if the symbola font is not just a stand-in proxy for "bad font, do extensive glyph fallback" ;-)
Marco reported he couldn't reproduce the exception with the listed font here; and is instead having to try to corrupt the font to get it to fail which is annoying =) perhaps Windows 10 is required somehow (?) or perhaps font installation is a problem - possibly embedding this in a standalone document that could crash on load would be a better test-case =)
Also knowing the list of build options could be helpful
(In reply to Marco Cecchetti from comment #9) > Also knowing the list of build options could be helpful I normally use Kendy's TB39 builds as he generates symbols. Kendy?
Created attachment 123923 [details] stacktrace when attemtping to embed Symbola font (In reply to Michael Meeks from comment #8) > Marco reported he couldn't reproduce the exception with the listed font > here; and is instead having to try to corrupt the font to get it to fail > which is annoying =) perhaps Windows 10 is required somehow (?) or perhaps > font installation is a problem - possibly embedding this in a standalone > document that could crash on load would be a better test-case =) On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: 379fb96dbd5ce0fdb0aaf5244d50583dc13d7611 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-26_14:01:39 Locale: en-US (en_US) Just attempted to edit a paragraph set default font to Symbola, to save and embed Symbola. Hmm, crash after setting the File -> Properties embed font box and trying to save (<Ctrl>+S, or Toolbar button). Clear the embed font box and its saves with no issue. Stacktrace for that attached. Is handling Symbola TTF somehow different on Windows font fallback? I know the font package is available for Linux/OS X builds--but LO font fallback is handled differently on those builds.
Hmm; can you turn off GL rendering in order to embed the font; > Just attempted to edit a paragraph set default font to Symbola, to save > and embed Symbola. Then again - your stack trace just looks like "deep badness in the font subsystem" in a way that is apparently un-related to GL ;-) > Hmm, crash after setting the File -> Properties embed font box and trying > to save (<Ctrl>+S, or Toolbar button). Clear the embed font box and > its saves with no issue. Perhaps another issue here; either way - we could do with the file with the font embedded; it -should- crash on load and first render if the font is embedded, and also it is used in text on the first page =) Thanks !
I am able to reproduce the bug but it is unrelated to what you reported earlier: - it occurs with both GL enabled and disabled - it occurs for any font face - it does not occur (at least) for any build earlier than March 21. In the end you hit a brand-new bug on the fly. :-) As for the original report (scrolling the combobox list of fonts crashes on reaching the Symbola entry): are you still able to reproduce it with current master ?
Created attachment 123937 [details] clip of document with Symbola SMP glyphs with default rendering So, on Windows 8.1 Ent 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: 6eb7cd38e348e8a9d6498bfc2d41e91725eb34aa CPU Threads: 8; OS Version: Windows 6.29; UI Render: default; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-16_12:53:35 Locale: en-US (en_US) I was able to save a document with fonts embedded including Symbola. Unfortunately it ends up in its ODF archive at 12.0 MB, and looking at the Fonts folder when unzipped Symbola is reasonable size of 2.19MB, and the usual "default" fonts are all under 400KB. But there is one unidentified "font"--listed at 18.2MB unpacked--9.5MB packed. Deleteing it corrupts the document--and looking in the content.xml it appears to actually be used, but the unzipped font does not open in a font viewer or resolve by file format. Not sure what it is. Unfortunately 12MB is just to big to post to the BZ. I'll have to PM you (Michael M. and Marco C.) a link to a OneDrive share. Attaching a clip of the document on Windows 8.1 with default rendering. OpenGL rendering show the issue Tor was fighting with of mispositioning of the SMP glyphs bug 97319 and bug 98709
Created attachment 123939 [details] stacktrace at winlayout.cxx for document with Symbola embedded So moved the document with Symbola embedded to my home system (Windows 10 Pro 64-bit en-US) with Version: 5.2.0.0.alpha0+ Build ID: 379fb96dbd5ce0fdb0aaf5244d50583dc13d7611 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-03-26_14:01:39 Locale: en-US (en_US) Test document opens, and interestingly, even with OpenGL enabled, with the fonts embedded I get corretly placed SMP glyphs, they are only cropped a bit. However, the Font Preview in the combobox list still crashed. Remains in winlayout.cxx but seem to have a different call to WinFontInstance::AddChunkOfGlyphs that is causing the SEH Exception crash.
Created attachment 123940 [details] hit debug breakpoint OK, ran this again and stepping over to run the analyze it looks like maybe someone set a debug breakpoint, hope it is of use.
Created attachment 123941 [details] with OpenGL and embedded SMP fonts -- glyphs positioned OK but clipped @Tor, This attachment for you, more for bug 97171 (or bug 98709) but shows that with font embedded the SMP glyphs are positioned correctly, but are being cropped in the vertical axis. Guess that is because when embedded we don't need to do font fallback?
Created attachment 124144 [details] WinDbg 64 stack trace of crash in dwrite with 64-bit symbols from TDF production build of 5.1.2.2 with font preview enabled On Windows 10 Pro 64-bit en-US with Version: 5.1.2.2 (x64) Build ID: d3bf12ecb743fc0d20e0be0c58ca359301eb705f CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) So, in addition to 32-bit TB39 master--also getting a crash with the TDF release build of 5.1.2.2 WinDbg 64-bit stacktrace with symbols attached--an issue here in the dwrite handling when populating the combobox with font previews. Maybe some better steps for others to reproduce: 1. Symbola font installed 2. open new Writer document 3. open special character dialog and select Symbola font 4. select a few characters from the BMP 5. insert into document Note: the Formatting toolbar "Font Name" for the paragraph now shows Symbola but displays in system font (Segoe UI). 6. add another paragraph or two or Symbola font, inserted from Special character dialog or typed 7. click the dropdown button to open the font preview combobox Note: the Symbola font name in the combobox list is rendered with Symbola font preview, the font name remains in system font 8. cursor arrow down to move down the font list, just a couple maybe to Tahoma 9. reverse direction in the list and use the up cursor arrow 10. reach Symbola again -- the font preview is rendered in Symbola, and "Font Name" box is in system Segoe UI 11. one final cursor arrow up moving above Symbola LO closes with document recovery error.
@Michael, Marco, * Just checked, and this exception does not occur when I disable OpenGL rendering for this build. With OpenGL disabled the combobox list of font previews renders without issue. Was again able to embed Symbola font into a Writer document and save it, but very large 12MB. Gave up on email, and our OwnCloud, so I've uploaded a test to the Wiki: https://wiki.documentfoundation.org/QA/Bugzilla/Attachments/Temporary_Storage_for_Big_Files https://wiki.documentfoundation.org/File:98710_testdoc_Symbola.zip
One more time I was not able to reproduce the problem, anyway a workaround is available here for review: https://gerrit.libreoffice.org/#/c/23892/
pushed to master; would love to have it tested =) Thanks !
Marco Cecchetti committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=92e33ae10d63b5acd8643d33c032dbb022bd75be tdf#98710 - catch exception due to crash in dwrite It will be available in 5.2.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.
Any feedback Stuart ? =)
(In reply to Michael Meeks from comment #23) > Any feedback Stuart ? =) Sorry, I've been waiting on a TB build to roll with patch from the 7th, all the Windows TBs have been down for a week. Last we've had to work with is 157469896ef56720f33676222b95e81c04ab5c72 from Cloph's TB62 at 2016-04-06_20:10:15
(In reply to Michael Meeks from comment #23) > Any feedback Stuart ? =) On Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha0+ Build ID: 3dca8575d63db50b0120fbff09bbfcd056fa3732 CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-04-20_05:07:29 Locale: en-US (en_US) Not much more detail in the DWrite crash in populating the FontName combo box with the new breakpoint set and working with OpenGL rendering enabled and scrolling by the Symbola font entry. FontName previews in the combo box are fine when OpenGL is disabled. clip from 32-bit WinDbg stack trace with TB39 Symbols. 0:000> ~* kp . 0 Id: 200.1da0 Suspend: 1 Teb: 00312000 Unfrozen ChildEBP RetAddr 0184c9a8 6ade0cd7 DWrite!FailAsExceptionPolicy<FileFormatException>::OnOutOfRange+0x23 0184ca0c 6ade7e99 DWrite!OpenTypeFace::OpenTypeFace+0xd0 0184ca38 6adeaa34 DWrite!OpenTypeFontFaceBuilder::OpenTypeFontFaceBuilder+0x34 0184ca70 6adeaa8a DWrite!FontFaceRegionBuilder::CreateInternal+0x47 0184cab0 6adc7149 DWrite!FontFaceRegionBuilder::Create+0x1c 0184cadc 6ade000b DWrite!FontFaceConstructionTask::AddElementData+0x29 0184cb5c 6adfbfde DWrite!CacheWriter::AddElement+0x23f 0184cba8 6adfcab8 DWrite!IBaseCacheContext::AddElementInternal+0x3e 0184cc28 6adff675 DWrite!ClientSideCacheContext::AddElementInternal+0x24 0184cc40 6adfc26c DWrite!DWriteFactory::AddElement+0x15 0184cc7c 6adfc36f DWrite!ElementTaskList::ExecuteTask+0x36 0184ccc0 6adfbde7 DWrite!ElementTaskList::GetElementData+0xdb 0184ccd4 6adfaec2 DWrite!IBaseCacheContext::GetElementData+0x17 0184cd5c 6adffe2f DWrite!FontFaceLight::FontFaceLight+0x132 0184cf10 6adfdd81 DWrite!FontFace::FontFace+0x2d 0184cf60 6ae08682 DWrite!DWriteFontFace::DWriteFontFace+0x31 0184cfb4 6ae40330 DWrite!DWriteFontFace::Create+0xfd 0184d288 6ae4001c DWrite!GdiFontFileLoader::CreateFontFace+0x14f 0184d2dc 67245ced DWrite!DWriteGdiInterop::CreateFontFaceFromHdc+0x7c 0184d430 67241e4b vcllo!D2DWriteTextOutRenderer::GetDWriteFaceFromHDC(struct HDC__ * hDC = 0xe00110a7, struct IDWriteFontFace ** ppFontFace = 0x0bb92a70, float * lfSize = 0x0bb92a74)+0x5d [c:\cygwin\home\tinderbox\master\vcl\win\gdi\winlayout.cxx @ 3927] 0184d458 672422b8 vcllo!D2DWriteTextOutRenderer::BindFont(struct HDC__ * hDC = 0xe00110a7)+0x9b [c:\cygwin\home\tinderbox\master\vcl\win\gdi\winlayout.cxx @ 3801] 0184da94 67243112 vcllo!WinFontInstance::CacheGlyphToAtlas(bool bRealGlyphIndices = false, int nGlyphIndex = 0n61549, class WinLayout * rLayout = 0x17958da8, class SalGraphics * rGraphics = 0x1790ec18)+0x458 [c:\cygwin\home\tinderbox\master\vcl\win\gdi\winlayout.cxx @ 386] 0184dacc 67244ca8 vcllo!SimpleWinLayout::CacheGlyphs(class SalGraphics * rGraphics = 0x1790ec18)+0x142 [c:\cygwin\home\tinderbox\master\vcl\win\gdi\winlayout.cxx @ 1464] 0184dba4 66ed2165 vcllo!WinLayout::DrawText(class SalGraphics * rGraphics = 0x1790ec18)+0xb8 [c:\cygwin\home\tinderbox\master\vcl\win\gdi\winlayout.cxx @ 1350] 0184dbd8 66ed0d79 vcllo!OutputDevice::ImplDrawTextDirect(class SalLayout * rSalLayout = 0x17958da8, bool bTextLines = false, unsigned long flags = 0)+0x1c5 [c:\cygwin\home\tinderbox\master\vcl\source\outdev\text.cxx @ 321] 0184dbf8 66ecc760 vcllo!OutputDevice::ImplDrawText(class SalLayout * rSalLayout = 0x17958da8)+0xe9 [c:\cygwin\home\tinderbox\master\vcl\source\outdev\text.cxx @ 476] 0184dd44 6b46f0ef vcllo!OutputDevice::DrawText(class Point * rStartPt = 0x0184ddd4, class rtl::OUString * rStr = 0x0184de38, long nIndex = 0n0, long nLen = 0n8, class std::vector<Rectangle,std::allocator<Rectangle> > * pVector = 0x00000000, class rtl::OUString * pDisplayText = 0x00000000)+0x4b0 [c:\cygwin\home\tinderbox\master\vcl\source\outdev\text.cxx @ 903] 0184de50 6bae1a36 svtlo!FontNameBox::UserDraw(class UserDrawEvent * rUDEvt = 0x0184df00)+0x6ef [c:\cygwin\home\tinderbox\master\svtools\source\control\ctrlbox.cxx @ 1291] 0184dec0 66e1583f svxcorelo!SvxFontNameBox_Impl::UserDraw(class UserDrawEvent * rUDEvt = 0x0184df00)+0x36 [c:\cygwin\home\tinderbox\master\svx\source\tbxctrls\tbcontrl.cxx @ 1155] 0184ded0 66e15faf vcllo!ComboBox::Impl::ImplUserDrawHdl(class UserDrawEvent * pEvent = 0x0184df00)+0x1f [c:\cygwin\home\tinderbox\master\vcl\source\control\combobox.cxx @ 1311] 0184dedc 66e4c2c3 vcllo!ComboBox::Impl::LinkStubImplUserDrawHdl(void * instance = 0x1752fee8, class UserDrawEvent * data = 0x0184df00)+0xf [c:\cygwin\home\tinderbox\master\vcl\source\control\combobox.cxx @ 1308]
I wonder if FileFormatException is a std::exception or whether this doesn't actually get to us: https://msdn.microsoft.com/en-us/library/windows/desktop/dd371185(v=vs.85).aspx has no mention of an exception. Stuart - are you certain that this exception is the problem - it is supposedly quite common - what happens if you just continue when it is triggered; what is the next failure ? not being able to reproduce this is indeed somewhat frustrating ! =) Thanks !
OK, so still with us--but I have more controlled STR! Also, it turns out issue is not with 'Symbola' fontface as in comment 4, and is even more of a corner case. Instead it is an issue with 'MS Symbol' a limited 188 glyph TTF/PS Type1 font with Private Use Area symbol encoding. Installed with older Office builds for use with the Equation editor. It is not Unicode compliant, and about half the glyphs in the font have no assigned mapping. The problem seems to come when I try to generate a font preview of the 'MS Symbol' font with OpenGL rendering enabled (so using DirectWrite). With default rendering, there are no issues with the font previews of 'Symbol'. Unfortunately "Symbol" is located before "Symbola" on the font listings. And that threw me while scrolling up or down in the Font list with previews enabled, as "Symbol" rolls into view on the list LibreOffice barfs--I incorrectly blamed "Symbola" because that was the last to show. As reported OpenGL rendering glitch affects the Font list combobox from the Style & Formatting toolbar when Tools -> Options -> View: Font lists "Show preview of fonts" is enabled. Two other places in the GUI that hang: 1) it affects Character Style dialog, which also has a font preview frame displayed and has to render the font. 2) it also affects the Special Character dialog. =-STR-= Since generating font preview with OpenGL rendering (and DirectWrite) causes SEH Exception in each area of the GUI, we don't need struggle to catch it while scrolling up or down in the font list with preview activated as originally in the summary. Instead: With MS Symbol present on a Windows system and OpenGL rendering enabled. 1. Open Writer 2. position edit cursor onto document canvas 3. context menu selection of the Character style dialog 4. in the font column, scroll to where "Symbol" font is visible in list 5. select font above or below "Symbol", note the name preview will render 6. select "Symbol" font, preview remains empty 7. SEH exception and close of LibreOffice Get a similar result with the Special Character dialog with OpenGL rendering enabled and selecting Symbol. Fonts either side fill the grid cells--MS Symbol hangs with SEH exception. Other PUA Symbol mapped typefaces do not seem to cause problems--I checked Opus Std and Opus Special. Both are fine, so something about the encoding of the 'MS Symbol' symbol fontface does not do well with DirectWrite. Posting two stacktraces with symbols (TB39) from Windows 10 Pro 64-bit en-US with Version: 5.2.0.0.alpha1+ Build ID: c70a5937e3a2057886c01bc78ac5a6b42e8c702d CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; TinderBox: Win-x86@39, Branch:master, Time: 2016-05-19_09:17:48 Locale: en-US (en_US)
Created attachment 125178 [details] with MS Symbol font installed -- hang with OpenGL enabled generating font preview in Character Style dialog
Created attachment 125179 [details] with MS Symbol font installed -- hang with OpenGL enabled generating glyph previews in Special Character dialog
Created attachment 125186 [details] with MS Symbol font installed -- hang with OpenGL enabled generating font preview in Character Style dialog, TB39 symbols a better stack trace with updated TB39 symbols
Created attachment 125187 [details] with MS Symbol font installed -- hang with OpenGL enabled generating glyph previews in Special Character dialog, TB39 symbols
Wow; great digging Stuart =) thanks - hopefully its easy to repeat now.
Created attachment 125849 [details] WinDbg Stacktrace wSymbols LO5.2.0rc1 On Windows 10 Pro 64-bit en-US with Version: 5.2.0.1 (x64) Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Locale: en-US (en_US) The font preview FontNameBox crash is still with us in LO 5.2.0rc1 WinDbg Stacktrace attached, also new crash reporting uploaded http://crashreport.libreoffice.org/stats/crash_details/ba3c83fb-e804-4bbc-bfd8-1f0ef4da1ebd
Created attachment 125850 [details] WinDbg Stacktrace wSymbols LO5.2.0rc1 -- Character style preview Alternate STR as in comment 27 also producing crash when "Symbol" font is selected. WinDbg 64 stack trace for that attached. On relaunch crash report submitted: crashreport.libreoffice.org/stats/crash_details/9e12b75d-5c1f-4c2e-925a-de46ef2e38ea
I get a crash when I select the old .fon fonts like "Script" and "Roman" because they aren't supported by Direct Write. That crash seems in the same place as this crashes. One of the problems is that we don't really check that the font is bound and proceed with rendering. I submitted a patch for master to [1] (I want to see if it builds on Windows) so I hope this will fix this issue. [1] https://gerrit.libreoffice.org/#/c/26885/
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=b5cd1220b849a9759dd4446032a7e1affbf151f2 tdf#98710 check the font is bound, substitute FON fonts It will be available in 5.3.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.
Stuart can you please check if this fixes the bug when the latest daily build is available. It may be an unrelated bug. Thanks.
(In reply to Tomaz Vajngerl from comment #37) > Stuart can you please check if this fixes the bug when the latest daily > build is available. It may be an unrelated bug. OK will do. Just gave Kendy, Cloph and Thorsten a nudge to check on their Windows TBs, been a while now with no Windows master builds.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3a9fb7a6bf34c7ad5647c4b84a91f43a41826dcd&h=libreoffice-5-2 tdf#98710 check the font is bound, substitute FON fonts It will be available in 5.2.0.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.
Tomaž Vajngerl committed a patch related to this issue. It has been pushed to "libreoffice-5-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=901bb8527350a81b1631338abedbfd3f77ffbf35&h=libreoffice-5-1 tdf#98710 check the font is bound, substitute FON fonts It will be available in 5.1.5. 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.
On Windows 8.1 Ent 64-bit en-US with Version: 5.3.0.0.alpha0+ Build ID: fc95bc132db20e7701088c76da6ec039031feadf CPU Threads: 8; OS Version: Windows 6.2; UI Render: GL; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-07-06_12:20:17 Locale: en-US (en_US); Calc: group Tomaž's commit(s) seems to have resolved the issue. No crash while performing preview of Symbol font in any of the noted STR. Also, bug 100747 crash on insert of PDF containing strings in Symbol font also resolved.