is there anything i can do about these (font lib) leaks?

[Dave Jordan]

they seem to be mostly re fonts

maybe i dont need some of these libs?

maybe there are alternatives?

i have tried updating libfontconfig and its a train wreck.

the following valgrind report is incomplete but typical:

416 (256 direct, 160 indirect) bytes in 1 blocks are definitely lost in loss record 412 of 563

??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
??? (in /usr/lib/x86_64-linux-gnu/libfontconfig.so.1.10.1)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
??? (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
XftDefaultHasRender (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
XftDefaultSubstitute (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
XftFontMatch (in /usr/lib/x86_64-linux-gnu/libXft.so.2.3.2)
Fl_Font_Descriptor::Fl_Font_Descriptor(char const*, int, int) (in /home/dave/progs/tylo/8/tylo)
fl_xft_font(Fl_Xlib_Graphics_Driver*, int, int, int) (in /home/dave/progs/tylo/8/tylo)

[Ian MacArthur]

On 24 Apr 2021, at 21:58, Dave Jordan wrote:
>
> they seem to be mostly re fonts
> maybe i dont need some of these libs?
> maybe there are alternatives?
> i have tried updating libfontconfig and its a train wreck.
> the following valgrind report is incomplete but typical:
>

When in the sequence do you see these reported?
If it is only on exit, then they may not really be leaks per se, just valgrind grumbling about things not being tidied away properly (if the process is exiting anyway, the memory will be reaped by the system, whether it is formally released by the exiting process or not...)
But: If they are occurring during runtime, and are accumulating over time, then that’s a leak.

[Dave Jordan]

it's definitely after Fl::run() returns (where i print the message "app window closed") and exit.

it still might be an accumulating leak, but even if not it still would be nice to get rid of the messiness (there's about 5x as many messages, all occurring on exit).

after all, i'm going out of my way to clean up that which IS under my control... but if i have to live with it then i guess i will.

[Ian MacArthur]

On 25 Apr 2021, at 02:49, Dave Jordan wrote:
>
> it's definitely after Fl::run() returns (where i print the message "app window closed") and exit.
> it still might be an accumulating leak, but even if not it still would be nice to get rid of the messiness (there's about 5x as many messages, all occurring on exit).
> after all, i'm going out of my way to clean up that which IS under my control... but if i have to live with it then i guess i will.

Maybe not...
Tradition dictates that at his point I (as I have many times before) recount this tale:
Once upon a time, many years ago, we had a placement student, fresh from University, and very keen.
As an introductory task they were set to doing some simple cleaning up of an existing codebase.
Taking to heart their lecturers exhortation to ensure they delete all the widgets that had been new’d, they set about “fixing” the “errors” in the codebase where it closed down without formally releasing all the widgets.

Net result? A slew of complaints from the end users that now, when they click exit, the app sits there for “like, 5 minutes” and then shuts down, whereas before it just closed “straight away”.
So, what happened here is that the “improved” code was now spending a significant time (not 5 minutes, but still noticeable) working it’s way through deleting everything, whereas previously it was simply exiting and allowing the OS to reap the released memory automatically.

The student was made to take out the improvements, and was enlightened.

[Greg Ercolano]

On 4/25/21 7:45 AM, Ian MacArthur wrote:

[..]

Taking to heart their lecturers exhortation to ensure they delete all the widgets that had been new’d, they set about “fixing” the “errors” in the codebase where it closed down without formally releasing all the widgets.

Net result? A slew of complaints from the end users that now, when they click exit, the app sits there for “like, 5 minutes” and then shuts down, whereas before it just closed “straight away”.
So, what happened here is that the “improved” code was now spending a significant time (not 5 minutes, but still noticeable) working it’s way through deleting everything, whereas previously it was simply exiting and allowing the OS to reap the released memory automatically.

The student was made to take out the improvements, and was enlightened.

    Nicely worded!

    Yeah, even early popular commercial applications had this problem too; I can't remember if it was
    SoftImage or Maya, but yeah, it would literally take minutes to exit the program because of all the
    destructors being called.

    Solution was easy enough, make an extra button in the UI that simlpy called _exit() and a wrapper script
    handled removing the temp files the program left behind.. exit time was now less than a second, lol

    For other programs that didn't allow custom exit buttons to be added, a tool that simply killed
    the running program's PID with 'kill -9', then a 'waitpid / rm of tmpfiles' sufficed.

[lifeatt...@gmail.com]

I, too, am bothered (distracted?) by Valgrind's messages about leaks I can't / don't need to do anything about.

Valgrind has a "message suppression" mechanism which I've not had a chance to investigate.

[Tigercat]

Fontconfig occasionally uses curious data structures, for example using offsets instead of pointers to access allocated memory. Valgrind gets confused.

Other system libraries have similar quirks, or allocate memory at startup that is only freed by the OS at exit, or whatever. Valgrind suppression files are your friend.

My valgrind suppression statement for fontconfig is:

{

   libfontconfig_Supress

   Memcheck:Leak

   fun:*alloc

   ...

   obj:/usr/lib64/libfontconfig.so.1.12.0

   ...

}

The first line is just an ID string. The other lines tell valgrind to ignore anything that happens in a function ending in 'alloc' in libfontconfig.so.1.12.0. The suppression file

usually has to be updated whenever the system libraries are updated.

Valgrind can help generate these suppression blocks if you run it with '--gen-suppressions=yes'. Then use '--suppressions=mysuppfile.supp' on your next valgrind run.

I like to edit the valgrind-generated suppressions to make them more general, eg, one '*alloc' line can block multiple alloc calls that valgrind finds problematical in a library.

The only caveat is that it's wise to first verify that it's not your program that is causing the memory leak, for example by calling the library API incorrectly. This is usually quite easy to do:

first, the library startup non-leaks are usually easily identified by the names at the bottom of the valgrind stack dump (ie if the leak started with a call to 'Init_Fontconfig()' it's

not likely anything you need to worry about), and second, use htop or some other monitor to verify your program isn't growing in size whenever it's doing something that

accesses the library API. Again, refer to the valgrind call stack to see where problems might exist before blindly adding suppressions to valgrind.

[Dave Jordan]

So many words of wisdom! Like a giant Valium. I shall sleep well and dream not of font management or little lost heap.

-dave

[Dave Jordan]

What's the word on releasing my progeny into the wild?

Should I post it here?

-dave

[Ian MacArthur]

On 4 May 2021, at 20:02, Dave Jordan wrote:
>
> What's the word on releasing my progeny into the wild?
> Should I post it here?

You can post announcements and links here, and if you are keen you can post links to the FLTK links page at: https://www.fltk.org/links.php

We don’t have any capacity for hosting source or binaries, so you’ll need some storage elsewhere for that - GitHub is probably the default option these days I guess.

[Dave Jordan]

ok that makes sense thank you

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/fltkgeneral/43FB3C65-C01B-439E-A75F-15AF2AF8051B%40gmail.com.