Re: Add a new function 'FcPatternRefCount'

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


> Le 5 juin 2023 à 14:59, Frederick Virchanza Gotham <cauldwell.thomas@xxxxxxxxx> a écrit :
> When people talk about a 'resource leak' or a 'memory leak', they are
> typically talking about a leak that gets progressively worse as the
> program runs for more and more time. So let's say a program allocates
> a buffer of 512 kilobytes every time you click an item in a tree view
> on screen, and so every time you click it, the memory usage increases
> and increases. So if you run the program on a server PC for two weeks
> straight then it could allocate a gig of RAM. These are the kinds of
> memory leak that we really need to fix.
> The other kind of memory leak is where memory is allocated only once
> and is supposed to remain accessible until the program ends. We don't
> need to free these allocations because the operating system frees all
> heap allocations when a program ends. However, these kinds of leaks
> can be cumbersome for debugging. If you build a wxWidgets program for
> Linux with GTK3, and if you use Address Sanitiser, then when the
> program ends you get a report of memory leaks from libpango. To get
> rid of this clutter, and also to be 100% certain that the leaks aren't
> accumulative, the debug build of the program should free these
> once-off allocations, perhaps by making use of the Standard C function
> 'atexit'.
> The patch I proposed to libpango uses the 'atexit' function to free
> all the once-off allocations when the program ends. It keeps calling
> FcPatternDestroy on an FcPattern until the internal counter reaches
> zero. So maybe there should be a function in libfontconfig that keeps
> destroying an FcPattern until the count is zero?

Pango/Fontconfig/wxWidgets should in theory free all the memory they allocate. If there are leaks, even if they look constant (but how do you know for sure they won't grow without understanding where they come from?), they should be figured out and eliminated by properly pairing increfs with decrefs. Your proposed patch is just papering over the problem, it's not solving it.

Jean [not a Fontconfig maintainer, unlike Akira]

[Index of Archives]     [Fedora Fonts]     [Fedora Users]     [Fedora Cloud]     [Kernel]     [Fedora Packaging]     [Fedora Desktop]     [PAM]     [Gimp Graphics Editor]     [Yosemite News]

  Powered by Linux