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

["Ulrich Windl" <Ulrich.Windl@xxxxxxxxxxxxxxxxxxxx>]

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

> 
> Am 19.02.21 um 08:44 schrieb Ulrich Windl:
>>>>> Lennart Poettering <lennart@xxxxxxxxxxxxxx> schrieb am 18.02.2021 um 19:30
>> in
>> Nachricht <YC6yQIX+7MFLvhmc@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





_______________________________________________
systemd-devel mailing list
systemd-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/systemd-devel