[poppler] A memory leak in GlobalParams::~GlobalParams()?

Albert Astals Cid aacid at kde.org
Thu Jan 21 11:56:06 PST 2010


A Dijous, 21 de gener de 2010, mpsuzuki at hiroshima-u.ac.jp va escriure:
> Hi,
> 
> On Wed, 20 Jan 2010 21:11:09 +0000
> 
> Albert Astals Cid <aacid at kde.org> wrote:
> >A Divendres, 15 de gener de 2010, mpsuzuki at hiroshima-u.ac.jp va escriure:
> >> I had ever reported a possibility of memory leak in
> >> CairoFreeTypeFont::create(), then, I found another
> >> possibility of memory leak in GlobalParams::~GlobalParams().
> >
> >I am not sure of that, FcConfigGetCurrent not always creates an object,
> 
> Oh, I'm sorry for missing the possibility that other
> part of software has already initialized "_fcConfig"
> and poppler just refers it via FcConfigGetCurrent().
> Thank you very much.
> 
> >as it can return you an already existing object, so deleting
> >on exit doesn't really seem wise as you could be removing
> >the object from underneath the feet of whoever else created
> >it (Qt, Pango, Cairo, etc)
> 
> I see. Checking fontconfig source, I found FcConfig
> has a reference counter, and FcConfigDestroy() checks
> it so that the client can prevent freeing the object
> in use.
> 
> fontconfig/src/fccfg.c
> 
>     233 void
>     234 FcConfigDestroy (FcConfig *config)
>     235 {
>     236     FcSetName   set;
>     237     FcExprPage  *page;
>     238
>     239     if (--config->ref > 0)
>     240         return;
>     241
>     242     if (config == _fcConfig)
>     243         _fcConfig = 0;
>     ...
> 
> However, FcConfigGetCurrent() does not increment the
> reference counter when it returns existing object.
> I will ask the correct procedure how to obtain FcConfig
> and free it in fontconfig mail list.

Yeah, i saw that too, thanks for following this up with them.

> 
> >So as you're supposed to only create one GlobalParams per
> >execution i don't think it's a problematic leak and will
> >vote for leaving it as it is.
> 
> Do you think it's a leak but not so serious to apply
> my wrong patch?  I understood my patch was wrong and
> must be reworked. Anyway, I attached valgrind logs of
> pdftotext, original one (LOG-20100121a.txt) and patched
> one (LOG-20100121b.txt).

I mean it is not a "real" leak, let me explain that, each application that 
uses poppler has (or should have) exactly one GlobalParams object, that gets 
constructed at the begining of the application and destroyed at the end. So 
"fixing" that leak is merely a "let's make it right" issue, i do not maen that 
it is not important, but i also mean we can perfectly live without this fixed 
forever and noone will notice.

Albert

> 
> Regards,
> mpsuzuki
> 


More information about the poppler mailing list