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
Created attachment 77104 [details] attachment with good mimetype
files are closed, other formats (txt...) ... OK
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.
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 ?
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
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-12-20
Any better with last stable LO version 5.2.2?
(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
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.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Any update with LO 6.4.3
(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
(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
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 }
I gave a try with https://gerrit.libreoffice.org/c/core/+/125636, I don't see the leaks anymore with GDIView.
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
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.
Jan-Marek: can we put this one as FIXED or do you want first cherry-pick your patch on 7.2 branch?
*** Bug 135844 has been marked as a duplicate of this bug. ***
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.