[systemd-devel] Antw: [EXT] Re: Looking for known memory leaks triggered by stress testing add/remove/up/down interfaces

[Reindl Harald]

Am 19.02.21 um 08:44 schrieb Ulrich Windl:
>>>> Lennart Poettering <lennart at poettering.net> schrieb am 18.02.2021 um 19:30
> in
> Nachricht <YC6yQIX+7MFLvhmc at gardel-login>:
> ...
>> entry instead of asking for new memory again. This allocation cache is
>> a bit quicker then going to malloc() all the time, but means if you
>> just watch the heap you'll assume there's a leak even though there
>> isn't really, the memory is not lost after all, and will be reused
>> eventually if we need it.
> 
> That's an interesting point of view: If you save memory in case you might need
> it at some unspecified later time (which includes "never") it's "practically"
> (while not theoretically) a memory leak

following that logic every memory pool and mysql buffer would be a memleak

a memleak is *unintended* and never freed memory allocation, practically 
as well as theoretically

you can argue about the size of such cases but it don't make them a 
memleak to begin with