[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Google
  Web www.spinics.net

Re: The reference counter handling in FcConfigGetCurrent() and FcConfigReference().



Hi,

What you are observing is simply that fontconfig is caching one instance of
FcConfig.  That's by design.  If you want that freed, you can call FcFini().
That's not a *leak*.  A leak is memory lost.  Forever.

behdad

On 01/21/2010 06:27 AM, mpsuzuki@xxxxxxxxxxxxxxxxx wrote:
> Dear fontconfig maintainers,
> 
> FcConfig object includes its reference counter, it prevents
> that FcConfigDestroy() frees an object in use. I think it's
> good design.
> 
> In the current implementation, I'm questionable about 2 points:
> 
> P1) FcConfigGetCurrent() does not increment the reference
>     counter when it returns existing FcConfig object.
> 
> P2) FcConfigReference() increments the reference counter
>     even when it returns new object created by FcConfigGetCurrent().
> 
> By P1, some libraries linking other libraries which uses
> fontconfig too cannot free FcConfig object safely.
> 
> For example, poppler links fontconfig by itself (to import
> font resources out of the document), and sometimes it links
> cairo (to render PDF to scalable graphics) which links
> fontconfig too.
> 
> The poppler invokes FcConfigGetCurrent() when it reads
> given PDF document, and sometimes cairo invoked by poppler
> invokes FcConfigGetCurrent() again, to write an output file.
> Unfortunately, the dependency of poppler onto cairo is
> not essential, so, poppler does not pass FcConfig object
> to cairo. Also no cairo API takes FcConfig object from
> the caller.
> 
> How we can free the object obtained by FcConfigGetCurrent()?
> In current implementation, we cannot know how many clients
> invoked FcConfigGetCurrent() from FcConfig->ref, so invoking
> FcConfigDestroy() is not safe. As a result, poppler does not
> invoke FcConfigDestroy() at all, although poppler frees an
> object including the reference to FcConfig obtained by
> FcConfigGetCurrent(). So, valgrind finds a memory leak in
> some programs. See recent discussion in poppler mail list:
> 
> http://lists.freedesktop.org/archives/poppler/2010-January/005429.html
> http://lists.freedesktop.org/archives/poppler/2010-January/005446.html
> http://lists.freedesktop.org/archives/poppler/2010-January/005453.html
> 
> FcConfigReference() looks slightly better about its handling
> of reference counter. Invoking FcConfigDestroy() for the
> object obtained by FcConfigReference( NULL ) is safer than
> the object obtained by FcConfigGetCurrent(). However, by P2,
> the minimum reference counter of the object obtained by
> FcConfigGetCurrent( NULL ) is 2, not 1. FcConfigGetCurrent()
> sets the reference counter to 1, and FcConfigReference()
> increments it. As a result,
>   - Invoke FcConfigReference( NULL ) once
>   - Invoke FcConfigDestroy( config ) twice
> is required for real freeing of the FcConfig object. This is
> not intuitive.
> 
> In summary, I want to propose following modifications:
> 
> M1) FcConfigGetCurrent() increments the reference counter
>     when it returns existing object.
> 
> M2) FcConfigDestroy() does not increment the reference
>     counter when it is invoked with NULL pointer and
>     FcConfigGetCurrent() is invoked.
> 
> Please give me comment.
> 
> Regards,
> mpsuzuki
> _______________________________________________
> Fontconfig mailing list
> Fontconfig@xxxxxxxxxxxxxxxxxxxxx
> http://lists.freedesktop.org/mailman/listinfo/fontconfig
> 
_______________________________________________
Fontconfig mailing list
Fontconfig@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/fontconfig

[Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Legacy]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Red Hat 9]     [Gimp]     [Yosemite News]

  Powered by Linux