Re: Memory Management
Re: Memory Management
- Subject: Re: Memory Management
- From: William Stewart <email@hidden>
- Date: Thu, 7 Sep 2006 15:22:12 -0700
There seems to still be some confusion about this, so I'll endeavour
to clarify this.
Firstly, if you follow the general guidelines and rules that are
required for mixing C and C++ allocations then there really should
not be any issues for you.
If you are not following these guidelines then any number of issues
can arise. One (of many) examples of some potential issues
- global operator new/delete are overridden (in other words, their
implementation is NOT the same as malloc/free).
This is legitimate practise allowed by the C++ runtime and the reason
these general guidelines exist is to allow for differences between
malloc and new and new [].
I'm not sure how to be clearer, but if you are mixing these
allocation and deallocation methods on the same allocated object,
then you are clearly in violation of required practise and you should
fix your code. As pointed out below, running auval with the Guard
Malloc options will crash an AU that is in violation of this
requirement. XCode 2.3 I think, also introduce a simple Option in the
Debug menu to enable Guard Malloc as well.
If you have any questions or comments, and you'd rather not post to
the list, feel free to contact me directly.
Thanks
Bill
On 28/08/2006, at 3:50 PM, William Stewart wrote:
We've had some reports recently about some problems with the usage
of the various memory allocation techniques and host apps and audio
units.
Some background:
There are three primary means to allocate and free memory in a C/C+
+ mixed environment. The allocations are done by 1 of:
(i) malloc (from stdlib.h in the std C library)
(ii) operator new
(iii) operator new []
Each of these calls MUST BE PAIRED with and only with, their
appropriate free operation:
(i) free
(ii) operator delete
(iii) operator delete []
These requirements are very explicitly a part of the C++ usage
rules, and the results of an incorrect pairing (for instance,
malloc/operator delete, or operator new/free, etc...) are
undefined. The various failure cases that can arise when these
operations are incorrectly paired, or the various usage scenarios
that can trigger problems, are probably too numerous to mention,
and an "apparent success" is just that - apparent(!).
So, we'd like to request that AU developers pay close attention to
their allocation strategies and make sure that they are using these
correctly. This can and does cause problems with some hosts that
are using more complex allocation strategies.
In the AUValidation read me (/Developer/Examples/CoreAudio/
AUValidation) we describe a couple of different testing strategies
that we strongly recommend every AU developer to both use and
become familiar with. The Guard Malloc option we believe will catch
many cases of incorrect pairing (the way it catches this is it
crashes with a bus error) - and in general the scribble/leaks
versions are also worth spending some time with.
Thanks
Bill
--
mailto:email@hidden
tel: +1 408 974 4056
______________________________________________________________________
____
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
______________________________________________________________________
____
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
mailto:email@hidden
tel: +1 408 974 4056
________________________________________________________________________
__
"Much human ingenuity has gone into finding the ultimate Before.
The current state of knowledge can be summarized thus:
In the beginning, there was nothing, which exploded" - Terry Pratchett
________________________________________________________________________
__
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden