Bug 98710 - Crash when GUI element shows a Preview of Fonts (STR comment 27) with new DirectWrite rendering
Summary: Crash when GUI element shows a Preview of Fonts (STR comment 27) with new Dir...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
5.2.0.0.alpha0+
Hardware: x86-64 (AMD64) Windows (All)
: highest normal
Assignee: Not Assigned
URL:
Whiteboard: target:5.2.0 target:5.3.0 target:5.2....
Keywords:
Depends on:
Blocks: VCL-OpenGL OpenGL
  Show dependency treegraph
 
Reported: 2016-03-16 16:27 UTC by V Stuart Foote
Modified: 2016-10-25 18:54 UTC (History)
9 users (show)

See Also:
Crash report or crash signature: ["WinFontInstance::CacheGlyphToAtlas(bool,int,WinLayout const &,SalGraphics &)"]


Attachments
WinDbg 32 stack trace of crash in dwrite when font preview enabled (35.44 KB, text/plain)
2016-03-17 05:09 UTC, V Stuart Foote
Details
font info for Symbola (32.98 KB, image/png)
2016-03-17 06:20 UTC, V Stuart Foote
Details
stacktrace when attemtping to embed Symbola font (21.00 KB, text/plain)
2016-03-29 14:59 UTC, V Stuart Foote
Details
clip of document with Symbola SMP glyphs with default rendering (54.46 KB, image/png)
2016-03-29 22:10 UTC, V Stuart Foote
Details
stacktrace at winlayout.cxx for document with Symbola embedded (19.92 KB, text/plain)
2016-03-30 01:58 UTC, V Stuart Foote
Details
hit debug breakpoint (2.68 KB, text/plain)
2016-03-30 02:20 UTC, V Stuart Foote
Details
with OpenGL and embedded SMP fonts -- glyphs positioned OK but clipped (97.42 KB, image/png)
2016-03-30 02:27 UTC, V Stuart Foote
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 (29.75 KB, text/plain)
2016-04-07 06:09 UTC, V Stuart Foote
Details
with MS Symbol font installed -- hang with OpenGL enabled generating font preview in Character Style dialog (18.79 KB, text/plain)
2016-05-20 02:18 UTC, V Stuart Foote
Details
with MS Symbol font installed -- hang with OpenGL enabled generating glyph previews in Special Character dialog (16.41 KB, text/plain)
2016-05-20 02:19 UTC, V Stuart Foote
Details
with MS Symbol font installed -- hang with OpenGL enabled generating font preview in Character Style dialog, TB39 symbols (25.05 KB, text/plain)
2016-05-20 08:31 UTC, V Stuart Foote
Details
with MS Symbol font installed -- hang with OpenGL enabled generating glyph previews in Special Character dialog, TB39 symbols (25.20 KB, text/plain)
2016-05-20 08:32 UTC, V Stuart Foote
Details
WinDbg Stacktrace wSymbols LO5.2.0rc1 (27.26 KB, text/plain)
2016-06-23 01:48 UTC, V Stuart Foote
Details
WinDbg Stacktrace wSymbols LO5.2.0rc1 -- Character style preview (31.25 KB, text/plain)
2016-06-23 01:59 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description V Stuart Foote 2016-03-16 16:27:36 UTC
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.
Comment 1 V Stuart Foote 2016-03-16 16:41:51 UTC
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.
Comment 2 V Stuart Foote 2016-03-17 05:09:23 UTC
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.
Comment 3 Tor Lillqvist 2016-03-17 05:17:40 UTC
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/ )
Comment 4 V Stuart Foote 2016-03-17 06:20:38 UTC
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.
Comment 5 V Stuart Foote 2016-03-17 07:39:18 UTC
--Linux packaging providing main source of Unicode 7.0 SMP Emoji--
Ubuntu -> ttf-ancient-fonts
openSUSE -> gdouros-symbola-fonts
Fedora/RHEL -> gdouros-symbola-fonts
Comment 6 V Stuart Foote 2016-03-20 17:57:03 UTC
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
Comment 7 Michael Meeks 2016-03-21 12:19:59 UTC
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" ;-)
Comment 8 Michael Meeks 2016-03-25 17:49:46 UTC
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 =)
Comment 9 Marco Cecchetti 2016-03-29 08:24:57 UTC
Also knowing the list of build options could be helpful
Comment 10 V Stuart Foote 2016-03-29 12:41:31 UTC
(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?
Comment 11 V Stuart Foote 2016-03-29 14:59:30 UTC
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.
Comment 12 Michael Meeks 2016-03-29 17:30:57 UTC
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 !
Comment 13 Marco Cecchetti 2016-03-29 18:37:37 UTC
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 ?
Comment 14 V Stuart Foote 2016-03-29 22:10:01 UTC
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
Comment 15 V Stuart Foote 2016-03-30 01:58:32 UTC
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.
Comment 16 V Stuart Foote 2016-03-30 02:20:46 UTC
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.
Comment 17 V Stuart Foote 2016-03-30 02:27:21 UTC
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?
Comment 18 V Stuart Foote 2016-04-07 06:09:35 UTC
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.
Comment 19 V Stuart Foote 2016-04-07 07:31:02 UTC
@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
Comment 20 Marco Cecchetti 2016-04-07 10:18:22 UTC
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/
Comment 21 Michael Meeks 2016-04-07 15:39:11 UTC
pushed to master; would love to have it tested =) Thanks !
Comment 22 Commit Notification 2016-04-07 15:41:42 UTC
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.
Comment 23 Michael Meeks 2016-04-11 08:48:40 UTC
Any feedback Stuart ? =)
Comment 24 V Stuart Foote 2016-04-11 12:34:27 UTC
(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
Comment 25 V Stuart Foote 2016-04-20 15:31:20 UTC
(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]
Comment 26 Michael Meeks 2016-04-20 15:48:22 UTC
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 !
Comment 27 V Stuart Foote 2016-05-20 02:16:48 UTC
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)
Comment 28 V Stuart Foote 2016-05-20 02:18:29 UTC
Created attachment 125178 [details]
with MS Symbol font installed -- hang with OpenGL enabled generating font preview in Character Style dialog
Comment 29 V Stuart Foote 2016-05-20 02:19:29 UTC
Created attachment 125179 [details]
with MS Symbol font installed -- hang with OpenGL enabled generating glyph previews in Special Character dialog
Comment 30 V Stuart Foote 2016-05-20 08:31:45 UTC
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
Comment 31 V Stuart Foote 2016-05-20 08:32:54 UTC
Created attachment 125187 [details]
with MS Symbol font installed -- hang with OpenGL enabled generating glyph previews in Special Character dialog, TB39 symbols
Comment 32 Michael Meeks 2016-05-20 09:37:32 UTC
Wow; great digging Stuart =) thanks - hopefully its easy to repeat now.
Comment 33 V Stuart Foote 2016-06-23 01:48:47 UTC
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
Comment 34 V Stuart Foote 2016-06-23 01:59:55 UTC
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
Comment 35 Tomaz Vajngerl 2016-07-04 01:40:44 UTC
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/
Comment 36 Commit Notification 2016-07-04 04:44:43 UTC
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.
Comment 37 Tomaz Vajngerl 2016-07-04 09:04:05 UTC
Stuart can you please check if this fixes the bug when the latest daily build is available. It may be an unrelated bug.

Thanks.
Comment 38 V Stuart Foote 2016-07-04 12:34:22 UTC
(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.
Comment 39 Commit Notification 2016-07-06 09:52:37 UTC
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.
Comment 40 Commit Notification 2016-07-06 09:52:44 UTC
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.
Comment 41 V Stuart Foote 2016-07-06 20:23:38 UTC
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.