Bug 106265 - Scrolling font list with previews enabled makes LO crash ( steps in comment 36 )
Summary: Scrolling font list with previews enabled makes LO crash ( steps in comment 36 )
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.2.2.2 release
Hardware: All Windows (All)
: highest critical
Assignee: Not Assigned
QA Contact:
URL:
Whiteboard: needsHighCountInstalledFonts target:5...
Keywords: haveBacktrace
: 102901 105431 107530 (view as bug list)
Depends on:
Blocks: Font-Rendering GDI-Limit
  Show dependency treegraph
 
Reported: 2017-03-01 22:38 UTC by Lynne Connolly
Modified: 2017-07-10 15:43 UTC (History)
14 users (show)

See Also:
Crash report or crash signature: ["SalFrame::SetCallback(vcl::Window *,bool (*)(vcl::Window *,SalEvent,void const *))"]


Attachments
crash dumps (177 bytes, text/plain)
2017-03-02 17:21 UTC, Lynne Connolly
Details
backtrace (16.11 KB, text/plain)
2017-03-08 01:09 UTC, Lynne Connolly
Details
WinDbg 64 stack trace of 5.3.2.2 and WinDbg 32 stack trace for TB39 master (23.45 KB, application/x-zip-compressed)
2017-05-02 00:09 UTC, V Stuart Foote
Details
WinDbg 32 stack trace and Analyze of TB39 crash dump (52.82 KB, text/plain)
2017-05-02 00:34 UTC, V Stuart Foote
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lynne Connolly 2017-03-01 22:38:14 UTC
I'm using the 64 bit version of LibreOffice 5.3.0.3 on Windows 10. This concerns Writer, which I use every day. 
I'd say this is a formatting problem. When I highlight text and try to change the font, if I scroll the font LibreOffice always crashes. It's fine if I change the name of the font by typing it in. This behavior is consistent. I have around 2000 fonts installed. 
If I change the font in Styles, the same thing happens if I try to scroll the fonts, rather than typing in the name. LO crashes.
Comment 1 Lynne Connolly 2017-03-01 23:05:34 UTC
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."
Comment 2 V Stuart Foote 2017-03-02 03:38:18 UTC
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.
Comment 3 V Stuart Foote 2017-03-02 03:53:23 UTC
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
Comment 4 V Stuart Foote 2017-03-02 04:06:40 UTC
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.
Comment 5 Lynne Connolly 2017-03-02 12:51:20 UTC
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.
Comment 6 V Stuart Foote 2017-03-02 13:44:50 UTC
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
Comment 7 Lynne Connolly 2017-03-02 17:21:09 UTC
Created attachment 131583 [details]
crash dumps
Comment 8 V Stuart Foote 2017-03-02 19:41:45 UTC
(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.
Comment 9 Lynne Connolly 2017-03-02 21:37:10 UTC
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!)
Comment 10 Aron Budea 2017-03-05 04:27:50 UTC
(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?
Comment 11 Lynne Connolly 2017-03-05 12:45:22 UTC
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.
Comment 12 Aron Budea 2017-03-08 00:47:56 UTC
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?
Comment 13 Lynne Connolly 2017-03-08 01:09:46 UTC
Created attachment 131737 [details]
backtrace
Comment 14 Lynne Connolly 2017-03-08 01:10:36 UTC
The graphics card is an Nvidia Geforce 960gtx 4gb.
Comment 15 Aron Budea 2017-03-08 02:53:20 UTC
Thanks for the backtrace!
Let's see if someone can analyze it, it does look quite unusual.
Comment 16 Yousuf Philips (jay) 2017-04-24 13:48:03 UTC
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/
Comment 17 V Stuart Foote 2017-04-24 14:50:54 UTC
@Lynne, do you by chance have the LT Language Tool extension installed?
Comment 18 Lynne Connolly 2017-04-25 02:34:03 UTC
yes, I have that extension installed.
Comment 19 V Stuart Foote 2017-04-25 03:19:42 UTC
(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.
Comment 20 Yousuf Philips (jay) 2017-04-25 03:58:15 UTC
(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
Comment 21 Buovjaga 2017-04-30 09:52:44 UTC
*** Bug 107530 has been marked as a duplicate of this bug. ***
Comment 22 Buovjaga 2017-04-30 10:05:22 UTC
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?
Comment 23 Yousuf Philips (jay) 2017-04-30 10:16:46 UTC
(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.".
Comment 24 Buovjaga 2017-04-30 10:37:32 UTC
(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.
Comment 25 Yousuf Philips (jay) 2017-04-30 10:56:52 UTC
(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?
Comment 26 V Stuart Foote 2017-04-30 13:10:36 UTC
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.
Comment 27 V Stuart Foote 2017-04-30 14:08:50 UTC
*** Bug 102901 has been marked as a duplicate of this bug. ***
Comment 28 Lynne Connolly 2017-04-30 16:46:29 UTC
No difference in the updated version. I'm away from home right now.
Comment 29 Lynne Connolly 2017-04-30 16:47:55 UTC
I don't want to uninstall Language Tool because it was a beast to get installed and working.
Comment 30 V Stuart Foote 2017-04-30 17:11:55 UTC
(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/
Comment 31 Lynne Connolly 2017-04-30 18:45:24 UTC
When I turn off java, it works!
Comment 32 Buovjaga 2017-04-30 18:54:23 UTC
Francisco: does disabling Java make the crashing go away for you as well?
Comment 33 V Stuart Foote 2017-04-30 20:21:10 UTC
(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?
Comment 34 Francisco 2017-04-30 23:59:50 UTC
(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.
Comment 35 Yousuf Philips (jay) 2017-05-01 12:02:35 UTC
(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.
Comment 36 V Stuart Foote 2017-05-02 00:09:05 UTC
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.
Comment 38 V Stuart Foote 2017-05-02 00:34:44 UTC
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
Comment 39 Markus Mohrhard 2017-05-02 00:54:05 UTC
(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.
Comment 40 V Stuart Foote 2017-05-02 02:53:52 UTC
(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
Comment 41 Aron Budea 2017-05-02 04:59:32 UTC
*** Bug 105431 has been marked as a duplicate of this bug. ***
Comment 42 Max Merbald 2017-05-02 10:20:05 UTC
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.
Comment 43 Xisco Faulí 2017-05-02 10:56:48 UTC
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
Comment 44 Max Merbald 2017-05-02 11:43:10 UTC
(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.
Comment 45 V Stuart Foote 2017-05-02 12:00:20 UTC
*** Bug 105431 has been marked as a duplicate of this bug. ***
Comment 46 V Stuart Foote 2017-05-02 14:55:17 UTC
(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.
Comment 47 Aron Budea 2017-05-02 23:03:17 UTC
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.
Comment 48 Noel Grandin 2017-05-06 13:16:21 UTC
@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.
Comment 49 Michael Meeks 2017-05-06 13:35:49 UTC
Tomaz reported that he has a ScopedGDI handle thing, that will clean this stuff up nicely and be exception safe too on the way =)
Comment 50 Commit Notification 2017-05-07 21:22:45 UTC
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.
Comment 51 V Stuart Foote 2017-05-08 03:23:12 UTC
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
Comment 52 Xisco Faulí 2017-05-09 09:28:43 UTC
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
Comment 53 Xisco Faulí 2017-05-09 09:51:51 UTC
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.
Comment 54 V Stuart Foote 2017-05-09 14:29:40 UTC
(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
Comment 55 V Stuart Foote 2017-05-09 14:35:44 UTC
(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
Comment 56 Buovjaga 2017-05-09 16:19:43 UTC
(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.
Comment 57 V Stuart Foote 2017-05-11 17:27:25 UTC
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
Comment 58 Commit Notification 2017-05-11 18:35:59 UTC
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.
Comment 59 Lynne Connolly 2017-05-15 02:04:43 UTC
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.