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

[Ulrich Windl]

>>> Reindl Harald <h.reindl at thelounge.net> schrieb am 19.02.2021 um 09:13 in
Nachricht <068b561d-677f-1abf-ef9f-0f43571e1acc at thelounge.net>:

> 
> 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

Database memory pools typically have a settable upper-bound.

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

So for every memory leak the programmer just has to say "that's intentional" and it's no longer a memory leak ;-)

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

With Lennart's explanation there are two unbounded dimensions: 1) the amount of "cache" 2) the time until actual re-use
(With 2) leading to 1) it seems)

Regards,
Ulrich