More details - I'm an author so I work on long documents, but they max out at around 80k words normally. There's no fancy formatting and no images. I use standard fonts for writing, like TNR, Book Antiqua, Georgia and Garamond. My CPU is 16 gb of Kingston Hyperfury, and the system is on an SSD in a tower. Just before the program crashes, I get the error message "bad allocation."

Would be interested in the crash reports for this. On restart are you presented with the option to file the report?  Please complete that process and post the link it lists.

Otherwise, suspect the high number of fonts is running you out of memory. For starters go to the Tools -> Options -> View panel and uncheck the "Show preview of fonts", that will make the drop list of fonts on the Formatting toolbar show simple Font names rather than previews, and likewise the drop list in the Sidebar Properties deck--Character--content panel.

See if working with the font preview disabled prevents the crash when scrolling the font lists--scrolling a list as previews is memory and CPU intensive.

Can not reproduce on Windows 10 Pro 64-bit en-US with
Version: 5.3.1.1 (x64)
Build ID: 72fee18f394a980128dc111963f2eefb05998eeb
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default-or-GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

We did have a similar issue with bug 102901--but that 

And the specific issue dealing with old MS .FON files, bug 98710 -- I specifically checked those STR and there is no recurrence of that issue.

@Lynne, is there any specific font you've installed that on you list of previews that seems to hang then crash--you can try to scroll downward and then upward to when producing a crash try to isolate it.

Also, does the crash occur with both OpenGL rendering (default on Windows when system supports it) and with Default rendering (activated when OpenGL support breaks).

Could you post the content from the Help -> About LibreOffice dialog.

Here's the info from the "about" dialog:
"Version: 5.3.0.3 (x64)
Build ID: 7074905676c47b82bbcfbea1aeefc84afe1c50e1
CPU Threads: 8; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; 
Locale: en-GB (en_GB); Calc: group"

Disabling the font preview does seem to stop it crashing. I've applied random faults to different documents and scrolled to get there, and so far, no crashes.
I can live with that, but it does seem to indicate a problem with the program. I've upped LO's memory allocation, but it didn't make any difference.
I did try repeating the problem with the CPU monitor open, and I didn't see a surge as I did it. 
I re-enabled "font preview" and bang - it happened again. So that seems pretty conclusive. I need the fonts for the graphics work, but I'll try editing them down a bit. I don't need all the fonts all the time!
However, my system is pretty high end, so it shouldn't have any problems with something of that nature. It's a custom-built rig, designed to deal with my usage, and it's barely a year old. I'm using Windows 10 Home. 
I'm an author, and I also do some graphics work, Photoshop mainly. Photoshop is solid as a rock, doesn't have any problems. This problem isn't enough to drive me back to Word (it would take a lot more to do that!) but I thought it was worth reporting.
Thanks for your help and your prompt replies.

Hey thank you for reporting! 

Could you post details for your Graphics card. LibreOffice stores that in your user profile. C:\Users\<username>\AppData\Roaming\LibreOffice\4\cache\opengl_device.log

But what we really need is a stack trace if we can not get the "automated" BreakPad based crash reporting to run. If it runs you'll get a dialog notice that LibreOffice had crashed and it will ask if you want to submit the report.

Otherwise need to do it manually attaching the crash dump to WinDbg with the symbol files for LibreOffice and MS Windows linked and downloaded.

Sorry it is a lot to work through, but if the automated reporting does not work in this case, you'll have to do it manually for us to make any progress.

The notes for getting WinDbg set up to do so are here:

https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg

but might also need you to test against nightly builds with most recent code updates. Details for that are here:

https://wiki.documentfoundation.org/Installing_in_parallel

Created attachment 131583 [details]
crash dumps

(In reply to Lynne Connolly from comment #7)
> Created attachment 131583 [details]
> crash dumps

Well that's not quite what we need as a crash dump, thanks for making the effort.

But it does show you are on a recent nVidia GPU with the 376.58 driver (2016-12-29). Which GPU chip, and which Card model?

You could probably update to current WHQL build of 378.66 (2017-02-14) but would not expect the GPU driver to actually make a difference here, your current is new enough to support graphic acceleration and OpenGL we use.

The card is an Nvidia Geforce 960, with a 4gb memory. It automatically updates so it's currently using the 14th Feb update. It copes smoothly with the demands Photoshop puts on it, including the fonts, so I don't think it's that.
I have gone through my font list and cut it down to 1800 active (I moved the ones I don't use very often into another file) and the problem seems to have stopped.
Still, I'd have thought LO could have coped with 2200, which is what I had before.

I've recently returned to LO, and I find it much improved with version 5.0, although of course there are a few things I'd love to see! (a tabbed interface!)

(In reply to V Stuart Foote from comment #6)
> But what we really need is a stack trace if we can not get the "automated"
> BreakPad based crash reporting to run. If it runs you'll get a dialog notice
> that LibreOffice had crashed and it will ask if you want to submit the
> report.

Lynne, did you get a dialog like this when LibreOffice is restarted after the crash?

No,just that the program had crashed and did I want it to restore the documents. But I do tend to switch crash reporting off when I install a program. I don't know how to switch it back on, but if I knew, I'd do it, crash the program and get the report.
I've created a new user profile and that made no difference. It's still crashing if I try to scroll fonts with font preview on.

I don't think LibreOffice's crash reporting can be switched off... or at least I haven't found how. But it doesn't always trigger, some crashes are harder to catch than others.

Is there a chance you could follow the steps Stuart outlined in comment 6, and provide a backtrace?

Created attachment 131737 [details]
backtrace

The graphics card is an Nvidia Geforce 960gtx 4gb.

Thanks for the backtrace!
Let's see if someone can analyze it, it does look quite unusual.

Hi Lynne,

I'd suggest you try the 32-bit version of LibreOffice 5.3 and the 32-bit version of LibreOffice 5.2 and see if those also crash for you.

https://www.libreoffice.org/download/download/

@Lynne, do you by chance have the LT Language Tool extension installed?

yes, I have that extension installed.

(In reply to Lynne Connolly from comment #18)
> yes, I have that extension installed.

Could you try removing Language Tools extension (it is Java based), but you might also disable the Java JRE--it is a checkbox on the Tools -> Options -> Advanced panel.

Check if that helps the font list to behave at least as well as does disabling the font preview as noted in comment 5.

(In reply to V Stuart Foote from comment #19)
> Check if that helps the font list to behave at least as well as does
> disabling the font preview as noted in comment 5.

Seems was mistaken and read Lynne reply incorrectly as he mention in comment 5, "Disabling the font preview does seem to stop it crashing."

@Lynne: Please test 5.2 when you get a chance. You dont have to install it, you can get the portable version from here. - http://download.documentfoundation.org/libreoffice/portable/5.2.6/LibreOfficePortablePrevious_5.2.6_MultilingualStandard.paf.exe

*** Bug 107530 has been marked as a duplicate of this bug. ***

Eh, not really a regression as font preview is a new feature. Should there be an internal switch to disable font preview when system has a certain number of fonts?

(In reply to Buovjaga from comment #22)
> Eh, not really a regression as font preview is a new feature. Should there
> be an internal switch to disable font preview when system has a certain
> number of fonts?

We've had font previews in the toolbar since 4.1 or so, you must be thinking of style previews in the sidebar. Also not sure why you changed the summary as Lynne said "Disabling the font preview does seem to stop it crashing.".

(In reply to Yousuf Philips (jay) from comment #23)
> (In reply to Buovjaga from comment #22)
> > Eh, not really a regression as font preview is a new feature. Should there
> > be an internal switch to disable font preview when system has a certain
> > number of fonts?
> 
> We've had font previews in the toolbar since 4.1 or so, you must be thinking
> of style previews in the sidebar. Also not sure why you changed the summary
> as Lynne said "Disabling the font preview does seem to stop it crashing.".

I didn't change the summary, though.

(In reply to Buovjaga from comment #24)
> I didn't change the summary, though.

Sorry, my bad. I must have mistakenly changed it on submission. :D

@Lynne: Any update from your side?

No reports, or QA testing, showing that this occurs on builds other than Windows. 

Also, disabling the font preview eliminates the crash.  Adjusting summary

Still need info on relationship of having the LANGAUGE TOOL extension installed and really need a solid STR and WinDbg stacktrace of the crash.

*** Bug 102901 has been marked as a duplicate of this bug. ***

No difference in the updated version. I'm away from home right now.

I don't want to uninstall Language Tool because it was a beast to get installed and working.

(In reply to Lynne Connolly from comment #29)
> I don't want to uninstall Language Tool because it was a beast to get
> installed and working.

No need, just do an "admin" install of recent build (5.3.2 or master)--but don't install the extension.

=-ref-=
https://wiki.documentfoundation.org/Installing_in_parallel/Windows

Note: be sure to adjust the User Configuration and edit the bootstrap.ini file as indicated.

http://downloadarchive.documentfoundation.org/libreoffice/old/

http://dev-builds.libreoffice.org/daily/master/

When I turn off java, it works!

Francisco: does disabling Java make the crashing go away for you as well?

(In reply to Lynne Connolly from comment #31)
> When I turn off java, it works!

Is that on a /a admin install (no Language Tools), or with your full install?

(In reply to Buovjaga from comment #32)
> Francisco: does disabling Java make the crashing go away for you as well?

Noups, the only thing that makes go away the crash is disabling OpenGL. Furthermore, I dont have any "languaje" extension, besides dictionaries. There's the Non-linear solver, Wiki publisher, and Mendeley citation manager there.

(In reply to Francisco from comment #34)
> Noups, the only thing that makes go away the crash is disabling OpenGL.
> Furthermore, I dont have any "languaje" extension, besides dictionaries.
> There's the Non-linear solver, Wiki publisher, and Mendeley citation manager
> there.

Then i think your issue is different from Lynne's, as he has openGL disabled, and your bug should be reopened to deal with your issue that has crash logs that devs can look through.

Created attachment 132998 [details]
WinDbg 64 stack trace of 5.3.2.2 and WinDbg 32 stack trace for TB39 master

Testing this on a Windows 8.1 Ent 64-bit system with nVidia GPU and ~1115 installed fonts set active with 
Version: 5.3.2.2 (x64)
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

STR

1. Open Writer
2. Formatting Toolbar -> Font Name box drop list
3. Scroll up and down the list
4. The previews are rendered correctly
5. continue scroll up and down until preview become garbled
6. continue to scroll up and down and crash

Recover and crash report against http://crashreport.libreoffice.org/stats/signature/SalFrame::SetCallback(vcl::Window%20*,bool%20(*)(vcl::Window%20*,SalEvent,void%20const%20*))

crashreport.libreoffice.org/stats/crash_details/4150ed68-d6bb-44d2-89f0-0dede76e1eb6

crashreport.libreoffice.org/stats/crash_details/4deecd40-226e-480b-ae04-f58ae779a503

Also tested same system with Version: 5.4.0.0.alpha1+
Build ID: c454fbb9b62164d5f047990ae63522c9fb932086
CPU threads: 8; OS: Windows 6.29; UI render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-05-01_04:48:39
Locale: en-US (en_US); Calc: CL

With 32-bit WinDbg attached while scrolling the Font Name box drop list preview also crash. Stack Trace attached.

(In reply to V Stuart Foote from comment #36)
> 
> Recover and crash report against
> http://crashreport.libreoffice.org/stats/signature/SalFrame::SetCallback(vcl:
> :Window%20*,bool%20(*)(vcl::Window%20*,SalEvent,void%20const%20*))
> 
Better links...

https://crashreport.libreoffice.org/stats/crash_details/4150ed68-d6bb-44d2-89f0-0dede76e1eb6

https://crashreport.libreoffice.org/stats/crash_details/4deecd40-226e-480b-ae04-f58ae779a503

https://crashreport.libreoffice.org/stats/crash_details/24dce9a8-cd06-4f00-baa4-8634ded6b2ab

Created attachment 132999 [details]
WinDbg 32 stack trace and Analyze of TB39 crash dump

another ST for TB39 master crash while scrolling the Font Name list box

(In reply to V Stuart Foote from comment #36)
> Created attachment 132998 [details]
> WinDbg 64 stack trace of 5.3.2.2 and WinDbg 32 stack trace for TB39 master
> 
> Testing this on a Windows 8.1 Ent 64-bit system with nVidia GPU and ~1115
> installed fonts set active with 
> Version: 5.3.2.2 (x64)
> Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
> CPU Threads: 8; OS Version: Windows 6.29; UI Render: GL; Layout Engine: new; 
> Locale: en-US (en_US); Calc: group
> 
> STR
> 
> 1. Open Writer
> 2. Formatting Toolbar -> Font Name box drop list
> 3. Scroll up and down the list
> 4. The previews are rendered correctly
> 5. continue scroll up and down until preview become garbled
> 6. continue to scroll up and down and crash
> 
> Recover and crash report against
> http://crashreport.libreoffice.org/stats/signature/SalFrame::SetCallback(vcl:
> :Window%20*,bool%20(*)(vcl::Window%20*,SalEvent,void%20const%20*))
> 
> crashreport.libreoffice.org/stats/crash_details/4150ed68-d6bb-44d2-89f0-
> 0dede76e1eb6
> 
> crashreport.libreoffice.org/stats/crash_details/4deecd40-226e-480b-ae04-
> f58ae779a503
> 
> Also tested same system with Version: 5.4.0.0.alpha1+
> Build ID: c454fbb9b62164d5f047990ae63522c9fb932086
> CPU threads: 8; OS: Windows 6.29; UI render: GL; 
> TinderBox: Win-x86@39, Branch:master, Time: 2017-05-01_04:48:39
> Locale: en-US (en_US); Calc: CL
> 
> With 32-bit WinDbg attached while scrolling the Font Name box drop list
> preview also crash. Stack Trace attached.


The stacktrace is not important for this issue. It is a resource leak where we run out of GDI handles and hit the windows process limit of 10k GDI handles.

However your instructions are quite valuable and I will see if I can reproduce it with them. If I understand the comments correctly and this is really related to OpenGL we seem to be leaking GDI handles somewhere in the OpenGL font rendering code.

(In reply to Markus Mohrhard from comment #39)
> However your instructions are quite valuable and I will see if I can
> reproduce it with them. If I understand the comments correctly and this is
> really related to OpenGL we seem to be leaking GDI handles somewhere in the
> OpenGL font rendering code.

Using same STR (comment 36) was able to reproduce crash on another Windows system with ~990 active fonts.

Windows 10 Pro 64-bit en-US with nVidia GPU and
Version: 5.3.2.2 (x64)
Build ID: 6cd4f1ef626f15116896b1d8e1398b56da0d0ee1
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

*** Bug 105431 has been marked as a duplicate of this bug. ***

Same thing here. LO 5.3.2.2, Win 10 Home Creator's Update, graphics card ist GeForce GTX 1050, when you scroll in the font list LO crashes showing a message: "bad allocation". When I de-select font preview it doesn't happen. I didn't, though, notice the rendered fonts becoming garbled. OpenGL for rendering is NOT activated.

I reproduced the 'bad allocation' error on Win 7 x86 without OpenGL enabled.

Steps:
1. Install 1000 fonts ( search 'big font pack' in Google )
2. Open attachment 128750 [details] from bug 103927
3. Select cell D18
4. Scroll down and up in the font droplist using the mouse wheel

(In reply to Xisco Faulí from comment #43)
> I reproduced the 'bad allocation' error on Win 7 x86 without OpenGL enabled.
> 
> Steps:
> 1. Install 1000 fonts ( search 'big font pack' in Google )
> 2. Open attachment 128750 [details] from bug 103927
> 3. Select cell D18
> 4. Scroll down and up in the font droplist using the mouse wheel

You don't need a specific file for this. The error also occurs when you just have an empty document.

*** Bug 105431 has been marked as a duplicate of this bug. ***

(In reply to Markus Mohrhard from comment #39)
 
> The stacktrace is not important for this issue. It is a resource leak where
> we run out of GDI handles and hit the windows process limit of 10k GDI
> handles.
> 

OK, so as indicated in bug 105469 watched process while running the NirSoft GDIview utility. With these STR LibreOffice dumps when the GDI object tally reaches 10,000 -- font object counts up to near the installed, but the Device Context (so hDC right?) continues to grow while scrolling the Font List box up and down.

The heart of the issue seems to be this call in WinFontInstance::CacheGlyphToAtlas(...):

HDC hNewDC = CreateCompatibleDC(hDC);
http://opengrok.libreoffice.org/xref/core/vcl/win/gdi/winlayout.cxx#60

Each pass through here increases GDI (DC) usage by 1, and I assume it's called for each glyph in the visible area of the font list.

@Aron I think you are on to something. That function has several return paths where it forgets to delete/deallocate hNewDC and hNonAntialiasedFont.
Would probably be best to wrap both of them in a RAII style delete on return thing.
The comphelper/scopeguard.hxx class is made for that.

Tomaz reported that he has a ScopedGDI handle thing, that will clean this stuff up nicely and be exception safe too on the way =)

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=dae61482df7ae540a1fb8feefbb92b5e7238444d

tdf#106265 ScopedHDC to clean-up hDC when rendering glyphs

It will be available in 5.4.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.

On Windows 10 Pro 64-bit en-US with
Version: 5.4.0.0.alpha1+
Build ID: c3e0b7dd4e7b1d33b8555e0acdf9f44cfc043ca2
CPU threads: 8; OS: Windows 6.19; UI render: GL; 
TinderBox: Win-x86@39, Branch:master, Time: 2017-05-08_00:14:11
Locale: en-US (en_US); Calc: CL

Monitoring with GDIview while scrolling--the Font count, and DC count are no longer leaking. soffice.bin maxing out at a more reasonable ~100 GDI objects while scrolling the font list with previews enabled.

@Lynne, please download a daily build of master and do a /a administrative install and test.  If no longer crashing for you--please set Resolve -> Fixed

Setting this bug to NEEDINFO is a mistake as it has been already confirmed. Putting it back to NEW.

I can no longer reproduce it in

Version: 5.4.0.0.alpha1+
Build ID: 9d320ec4d818f86e58a15fd46248026502b1cc94
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-09_01:27:12
Locale: es-ES (es_ES); Calc: group

@Tomaz, Could you please close this as RESOLVED FIXED once you think your work is done on this bug ?

@Stuart, I found another bug with the same 'bad allocation' problem -> bug 98558. Could you please check if the number of GDI object increase up to 10.000 before the crash? In my case, GDIView didn't even show any difference when I reproduced this issue before tomaz's fix

Hi again,
Just for your information, I could manage to reproduce the 'bad allocation' problem again in

Version: 5.4.0.0.alpha1+
Build ID: 9d320ec4d818f86e58a15fd46248026502b1cc94
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-09_01:27:12
Locale: es-ES (es_ES); Calc: group

In order to reproduce it I scrolled up and down but this time it took me much more time than before to reproduce it.

(In reply to Xisco Faulí from comment #52)
> Setting this bug to NEEDINFO is a mistake as it has been already confirmed.
> Putting it back to NEW.
> 

The NEEDINFO was to Lynne to test the patch.

> 
> @Stuart, I found another bug with the same 'bad allocation' problem -> bug
> 98558. Could you please check if the number of GDI object increase up to
> 10.000 before the crash? In my case, GDIView didn't even show any difference
> when I reproduced this issue before tomaz's fix

Don't think they are related...

Tested on Windows 10 Pro 64-bit en-US with
Version: 5.3.3.2 (x64)
Build ID: 3d9a8b4b4e538a85e0782bd6c2d430bafe583448
CPU Threads: 8; OS Version: Windows 6.19; UI Render: GL; Layout Engine: new; 
Locale: en-US (en_US); Calc: group

Opening and working in that spreadsheet the GDI count remained lowish < 500 total while manipulating the sheet and chart, though memory consumption is a bit high > 450MB, avg ~390MB.  While with that build scrolling the Font List would run up the GDI count with HC and Font leaks.

But with a 32-bit build of master I also got the "bad allocation" WinDbg 32-bit StackTrace attached to bug 98559 -- it is not the GDI issue.

Version: 5.4.0.0.alpha1+
Build ID: 9d320ec4d818f86e58a15fd46248026502b1cc94
CPU threads: 8; OS: Windows 6.2; UI render: GL; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-09_01:27:12
Locale: en-US (en_US); Calc: CL

(In reply to V Stuart Foote from comment #54)
> But with a 32-bit build of master I also got the "bad allocation" WinDbg
> 32-bit StackTrace attached to bug 98559 -- it is not the GDI issue.

Sorry,

s/98559/98558 so bug 98558

(In reply to V Stuart Foote from comment #54)
> (In reply to Xisco Faulí from comment #52)
> > Setting this bug to NEEDINFO is a mistake as it has been already confirmed.
> > Putting it back to NEW.
> > 
> 
> The NEEDINFO was to Lynne to test the patch.

The status is only used against unconfirmed reports.

OK, comfortable calling it resolved. 

@Lynne could you please verify on your system with a /a admin install of master (links as in comment 30).

Meanwhile ESC agreed to a backport for 5.3, up for code review in ref.

=-ref-=
https://gerrit.libreoffice.org/#/c/37495

Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=e5294137948cf31a972d1c29088b80f7730a8414&h=libreoffice-5-3

tdf#106265 ScopedHDC to clean-up hDC when rendering glyphs

It will be available in 5.3.4.

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.

Thank you so much! The delay was because I was away on a business trip, and the hotel internet couldn't cope with anything more complicated than an email! I tested the daily, and it works beautifully. I really appreciate your work on this.

*** Bug 107023 has been marked as a duplicate of this bug. ***

I think this bug still persists in 5.4.0.3 (Win64), I have created a new bug report with this same crash #112180 with the font file that causes the crash attached

I just checked. Yes, unfortunately, it does.

A fix to bug 112180 was committed today, Lynne please test with a fresh daily build tomorrow or afterwards.

If that doesn't help, I wonder what could've changed in the past 6 months (the bug in bug 112180 was there all along, though). In this case please open a follow-up bug report, and add it to the See Also field.

*** Bug 108303 has been marked as a duplicate of this bug. ***