At 2:54 PM -0800 3/26/99, Kenneth Albanowski wrote:
>No, almost certainly the OS will not find the leaked memory and free it
>when you delete the offending hack. There is not (or there didn't use to
>be) any label saying which database owned a block of heap memory. (There
>is a label saying which running task owns a block of heap memory, which
>you can erase to stop the OS from freeing blocks when you exit.)
There are two types of heap -- dynamic and storage.
Dynamic:
The OS normally cleans up leaked dynamic heap chunks (MemPtrNew) when an
app quits.
If a hack just calls MemPtrNew, the block should look like it's owned by
whatever app is running, and it will get cleaned up when that app exits.
If the hack calls Mem{Ptr|Handle}SetOwner to set the owner to 0 (the
system), then the chunk will not be reclaimed, ever.
A regular reset re-inits the dynamic heap, so any leaks are gone at that point.
Storage:
Apps don't normally allocate chunks directly in the storage heap, most
chunks belong to some database, however DmNewHandle will allocate an
un-owned chunks.
Data in the storage heap isn't cleaned up at all when an app quits. If you
leak here, the leak will persist.
However, a regular reset will do a cleanup on the storage heap, where the
data manager looks at all the chunks and explicitly deletes any of them
which do not belong to any database. Leaked DmNewHandle chunks and
FeaturePtrs in the 3.1 and later OS, for example, get cleaned up by this
mechanism.
--Bob
