https://bugs.documentfoundation.org/show_bug.cgi?id=62812
--- Comment #14 from Julien Nabet <serval2...@yahoo.fr> --- 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 } -- You are receiving this mail because: You are the assignee for the bug.
