Bug 62812 - writer_pdf_Export Font GDI handle leaks
Summary: writer_pdf_Export Font GDI handle leaks
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
4.0.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.3.0
Keywords: filter:pdf
: 135844 (view as bug list)
Depends on:
Blocks: PDF-Export GDI-Limit
  Show dependency treegraph
 
Reported: 2013-03-27 13:50 UTC by flajs.email
Modified: 2022-07-10 11:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
GDI view, Font handle are not released ! (93.05 KB, image/png)
2013-03-27 13:50 UTC, flajs.email
Details
attachment with good mimetype (93.05 KB, image/png)
2013-03-27 13:54 UTC, flajs.email
Details

Note You need to log in before you can comment on or make changes to this bug.
Description flajs.email 2013-03-27 13:50:10 UTC
Created attachment 77103 [details]
GDI view, Font handle are not released !

GDI view, Font handle are not released !

Batch conversion from RTF->PDF

after 1700 iteration of converted files are GDI handles fill 
GDI Font object isn't released.

how to reproduce:
1) connection to LO

2) while (i < 1800)
3) open RTF (with arial font, bold font .... etc, multiple file)
4) export to PDF (PDF 1.4 or A)
5) loop
Comment 1 flajs.email 2013-03-27 13:54:11 UTC
Created attachment 77104 [details]
attachment with good mimetype
Comment 2 flajs.email 2013-03-27 13:57:35 UTC
files are closed,
other formats (txt...) ... OK
Comment 3 Joel Madero 2013-03-27 14:05:05 UTC
This is not a critical bug if it exists.

Also what are you using to do your batch conversion? Marking as NEEDINFO as we need more explicit steps on how to reproduce the bug. Please be as explicit as possible when describing steps for a bug, especially slightly more complicated bugs that include batch changes.

Once you provide steps please mark as UNCONFIRMED and we shall try to triage the issue.
Comment 4 flajs.email 2013-03-28 07:39:25 UTC
Simplest  scenario for a reproduction bug:

1) Execute LibreOffice 4.0.1.2 on Windows 7 
2) Create new document in Writer
3) write several words with fonts Arial, Arial Bold, Times New Roman etc

4) Run GDIView - applikaction for monitoring windows objects resources
   DC, Fonts, etc.
   http://www.nirsoft.net/utils/gdi_handles.html

5) Export this document to PDF 
6) Check GDIView (F5 refresh) on soffice.bin process -> Font object growth
7) repeat steps 5,6

It's info OK ?
Comment 5 Buovjaga 2014-10-22 11:59:59 UTC
I did as instructed in comment 4 and observed the font count increase after every PDF export, so I'm setting this as NEW.
Version: 4.4.0.0.alpha1+
Build ID: a8c24b25fd9fb21097a08a22797bf61b59099ea1
TinderBox: Win-x86@39, Branch:master, Time: 2014-10-21_06:33:33
Comment 6 QA Administrators 2015-12-20 16:15:57 UTC Comment hidden (obsolete)
Comment 7 Julien Nabet 2016-11-06 20:49:38 UTC Comment hidden (obsolete)
Comment 8 Buovjaga 2016-11-09 08:01:31 UTC
(In reply to Julien Nabet from comment #7)
> Any better with last stable LO version 5.2.2?

Still growing.

Win 7 Pro 64-bit Version: 5.3.0.0.alpha1+
Build ID: 63bd9cf4ad268d83677baf99ec509ef67b5de08a
CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; Layout Engine: new; 
TinderBox: Win-x86@39, Branch:master, Time: 2016-11-07_01:55:57
Locale: fi-FI (fi_FI); Calc: group
Comment 9 Xisco Faulí 2017-06-19 09:38:10 UTC
Some fixes have been done to the GDI handles recently.
Could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ?
You can install it alongside the standard version.
Comment 10 QA Administrators 2018-06-20 02:49:03 UTC Comment hidden (obsolete)
Comment 11 Julien Nabet 2020-05-19 14:40:50 UTC
Any update with LO 6.4.3
Comment 12 Buovjaga 2020-05-19 18:34:55 UTC Comment hidden (obsolete)
Comment 13 Buovjaga 2020-05-19 18:35:33 UTC
(In reply to Buovjaga from comment #12)
> (In reply to Julien Nabet from comment #11)
> > Any update with LO 6.4.3
> 
> Still repro with steps from comment 4
> 
> Arch Linux 64-bit
> Version: 7.0.0.0.alpha1+
> Build ID: 809ddff82dc9a28051d8f6b0d6513b1824ba0ab9
> CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; 
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded
> Built on 19 May 2020

Bleh, make that
Version: 7.0.0.0.alpha1+ (x64)
Build ID: 4804d969bacd25ad586b3bf70d3dc8c27adb48ef
CPU threads: 4; OS: Windows 10.0 Build 18362; UI render: default; VCL: win; 
Locale: fi-FI (fi_FI); UI: en-US
Calc: threaded
Comment 14 Julien Nabet 2021-11-21 19:59:11 UTC
Thanks to https://www.codeproject.com/Articles/5306193/Find-GDI-Leaks-With-Windows-Debugger, I found some GDI leaks when exporting in PDF.

Here are 2 parts of bts retrieved from Windbg.
Since the pb was font GDIs, I used the line of the quoted website:
bm gdi32!createfont* "kp"

1)
00 000000ac`99380e38 00007ffd`34f3d2e1 GDI32!CreateFontIndirectW
01 000000ac`99380e40 00007ffd`34f3cc26 vclplug_winlo!WinSalGraphics::ImplDoSetFont(class vcl::font::FontSelectPattern * i_rFont = 0x000000ac`99381000, class vcl::font::PhysicalFontFace * i_pFontFace = 0x000001e8`6b09c880, struct HFONT__ ** o_rOldFont = 0x000000ac`99380f98)+0x61 [C:\cygwin\home\serva\lode\dev\core\vcl\win\gdi\salfont.cxx @ 823] 
02 000000ac`99380f40 00007ffd`3ebb6002 vclplug_winlo!WinSalGraphics::GetGlyphWidths(class vcl::font::PhysicalFontFace * pFont = 0x000001e8`6b09c880, bool bVertical = false, class std::vector<long,std::allocator<long> > * rWidths = 0x000001e8`20aa6ad0, class std::map<char16_t,unsigned long,std::less<char16_t>,std::allocator<std::pair<char16_t const ,unsigned long> > > * rUnicodeEnc = 0x000001e8`20aa6af0)+0xa6 [C:\cygwin\home\serva\lode\dev\core\vcl\win\gdi\salfont.cxx @ 1650] 

2)
00 000000ac`9937f5a8 00007ffd`34f3d2e1 GDI32!CreateFontIndirectW
01 000000ac`9937f5b0 00007ffd`34f3a760 vclplug_winlo!WinSalGraphics::ImplDoSetFont(class vcl::font::FontSelectPattern * i_rFont = 0x000000ac`9937f7f0, class vcl::font::PhysicalFontFace * i_pFontFace = 0x000001e8`65620770, struct HFONT__ ** o_rOldFont = 0x000000ac`9937f798)+0x61 [C:\cygwin\home\serva\lode\dev\core\vcl\win\gdi\salfont.cxx @ 823] 
02 000000ac`9937f6b0 00007ffd`3ec480d4 vclplug_winlo!WinSalGraphics::CreateFontSubset(class rtl::OUString * rToFile = 0x000000ac`9937f978 "file:///C:/cygwin/tmp/5330.tmp", class vcl::font::PhysicalFontFace * pFont = 0x000001e8`65620770, unsigned short * pGlyphIds = 0x000000ac`99381340, unsigned char * pEncoding = 0x000000ac`99381240 "", long * pGlyphWidths = 0x000000ac`99380e40, int nGlyphCount = 0n4, class FontSubsetInfo * rInfo = 0x000000ac`9937fb80)+0xc0 [C:\cygwin\home\serva\lode\dev\core\vcl\win\gdi\salfont.cxx @ 1554] 

If we focus on first bt, we have in WinSalGraphics::GetGlyphWidths:
1646     HFONT hOldFont = nullptr;
1647     ImplDoSetFont(aIFSD, pFont, hOldFont);
See https://opengrok.libreoffice.org/xref/core/vcl/win/gdi/salfont.cxx?r=3f5fb075#1647

But let's take a look at ImplDoSetFont
    818     HFONT hNewFont = nullptr;
...
    823     hNewFont = ::CreateFontIndirectW( &aLogFont );
...
    855     return hNewFont;

See https://opengrok.libreoffice.org/xref/core/vcl/win/gdi/salfont.cxx?r=3f5fb075&mo=24673&fi=814#814

So ImplDoSetFont creates a GDI font object and returns it.
In our case, we don't retrieve the value so it leaks.

Now, let's search calls to ImplDoSetFont in Opengrok.
https://opengrok.libreoffice.org/s?refs=ImplDoSetFont&project=core
It's been called in 3 different locations in salfont.cxx
1) CreateFontSubset() (the second bt)
2) GetEmbedFontData()
3) GetGlyphWidths() (the first bt we focused)

It's also called in WinFontInstance::SetGraphics() from /vcl/win/gdi/winlayout.cxx
but here we got:
m_hFont = m_pGraphics->ImplDoSetFont(GetFontSelectPattern(), GetFontFace(), hOrigFont);
and its destruction is managed in dtor:
    115 WinFontInstance::~WinFontInstance()
    116 {
    117     if (m_hFont)
    118         ::DeleteFont(m_hFont);
    119 }
Comment 15 Julien Nabet 2021-11-21 20:04:11 UTC
I gave a try with https://gerrit.libreoffice.org/c/core/+/125636, I don't see the leaks anymore  with GDIView.
Comment 16 Julien Nabet 2021-11-22 13:27:54 UTC
I unassigned myself since I abandoned my patch.
Good news is Jan-Marek is preparing a far better patch here:
https://gerrit.libreoffice.org/c/core/+/125652
Comment 17 Commit Notification 2021-11-23 18:30:31 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/c2a581ffc1f4e3888c5c243932b71c3d96e8ba8f

tdf#62812 WIN use a compatible DC for font funcs

It will be available in 7.3.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 18 Julien Nabet 2021-11-24 17:10:28 UTC
Jan-Marek: can we put this one as FIXED or do you want first cherry-pick your patch on 7.2 branch?
Comment 19 Mike Kaganski 2022-04-08 11:29:08 UTC
*** Bug 135844 has been marked as a duplicate of this bug. ***
Comment 20 Julien Nabet 2022-07-10 11:06:13 UTC
Since 7.2 branch is EOL (see https://wiki.documentfoundation.org/ReleasePlan/7.2) let's consider this one as FIXED.

If someone finds GDI leaks with LO 7.3.4 min, don't hesitate to reopen this tracker.