[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSZoneMalloc() vs. objc_malloc() vs. malloc() ...
From: |
Richard Frith-Macdonald |
Subject: |
Re: NSZoneMalloc() vs. objc_malloc() vs. malloc() ... |
Date: |
Mon, 13 May 2002 18:23:38 +0100 |
On Monday, May 13, 2002, at 03:23 PM, Kai Henningsen wrote:
I just tried to supply my own memory management routines via the
_objc_malloc etc. hooks. The program promptly died.
On investigation, it seems that GNUstep is mixing all three
allocation systems from the subject, allocating stuff via one variant
and freeing it via another (the one that just bit me is
NSFileManager, allocating via custom_strdup via NSZoneMalloc() [and
shouldn't that have been NSZoneMallocAtomic()?] and freeing via
gsedRelease via free().)
Fixing this seems a fairly mechanical task - *except* one would first
need a clear direction on what should actually be used. (I'm assuming
here that we *don't* want to use different allocation routines in
different parts of the library, except when implementing same.)
Comments?
I think all malloc/free type operations using GNUstep code should go
through the NSZone... system. The NSFileManager call to free() is
plainly a bug.
Within the base library, some internals might need to work differently
for instance, allocation of a mutex and other operations working with the
data structures of the objc runtime should use objc_malloc()
When dealing with memory passed to/from system calls and C library
functions,
we should be using malloc/free if those system calls are going to use
malloc/free.