All the allocated memory is more or less held in a pointer for a reference. When it is discarded, it can be considered as EOL and can be freed and has to be freed in general. In some cases, it keeps allocated for caching etc until applications ends. they could be freed at shutting down, FROM such references. You made your own array to store references and are going to ignore this basic logic of the memory management. Also, the reference counting system is supposed to call unref as many as they call ref. no need to know how much number they are referenced as long as they are freed appropriately. On Mon, Jun 5, 2023 at 9:59 PM Frederick Virchanza Gotham <cauldwell.thomas@xxxxxxxxx> wrote: > > On Mon, Jun 5, 2023 at 10:26 AM Akira TAGOH <akira@xxxxxxxxx> wrote: > > > > Another point is, there is no way to know what objects are really used > > or not. introducing such functions may introduce unexpected behavior. > > freeing all the FcPattern instances at exiting, as you proposed at > > https://gitlab.gnome.org/GNOME/pango/-/issues/750 doesn't fix anything > > for users because unwanted memory still keeps allocated as long as it > > keeps running. What if it is huge and often happens? Do you suggest > > restarting apps so often and many times? > > > 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? -- Akira TAGOH
