From hns at goldelico.com  Sun Jan  2 22:03:13 2022
From: hns at goldelico.com (H. Nikolaus Schaller)
Date: Sun, 2 Jan 2022 22:03:13 +0100
Subject: [QuantumSTEP] Fixed severe memory leak bug in ARP
Message-ID: <312B2B99-FB94-4944-8ED6-B2B5BC8833F8@goldelico.com>

Hi,

after several testing sessions and adding more test rig to
the source code, I was able to find and fix a memory leak
that was known for a while but the reasons were not...

The leak manifested itself in such simple things that the
loginwindow application did eat up memory more and more
even if a LetuxOS device was not operated otherwise.

It was introduced some years ago and never satisfactorily
solved because I though that it is an AppKit issue.

Leakage was so much that the Linux kernel on a typical
512 MB RAM machine (e.g. GTA04) did kill the loginwindow
process after ca. 1 hour due to out of memory situation.

Long research did show that the ARP cache pool was the
reason. It turned out that an ARP retain & dealloc sequence
did push an ARP object with retainCount=0 and a new
allocWithZone did pop with retainCount=0. This made it
different from a really new allocation if there was no ARP
object in the cache or the cache was disabled.

Everything did run fine afterwards - until the code using
the ARP (e.g. NSString or NSLog) did call [pool release].
This did no longer dealloc the ARP and so it was not drained.
So more and more unemptied ARPs were sitting in memory.

This has been fixed by incrementing the refCount if
needed. And another safety guard is to check recCount
to be non-zero when release is called.

This may also help to find other bugs in other frameworks
or applications.

After fixing this the memory allocation is now very
stable as an optional call to __NSPrintAllocationCount()
in NSRunLoop can show.

Source code repo of mySTEP has been updated as well as
the prebuilt Debian packages. So please run apt-get update
and apt-get upgrade. And please report problems and crashes.

-- hns