Re: CloseComponent
Re: CloseComponent
- Subject: Re: CloseComponent
- From: "Sandeep Chandna" <email@hidden>
- Date: Fri, 12 Jan 2007 14:54:44 +0530
Brad, I was actually doing CFRelease on the CFStrings. Thanks, now it works.
Jim, that was really insightful.
Thanks
Sandeep
On 12/01/07, Jim Wintermyre <email@hidden> wrote:
At 8:50 AM -0800 1/11/07, Brad Ford wrote:
>On Jan 10, 2007, at 10:34 PM, Sandeep Chandna wrote:
>
>> Hi,
>>
>> To get the list of supported audio codecs in Quicktime I am doing
>> the following:
>>
>> OpenADefaultComponent(StandardCompressionType,
>> StandardCompressionSubTypeAudio, &ci);
>>
>> QTGetComponentPropertyInfo
>> (ci,kQTPropertyClass_SCAudio,kQTSCAudioPropertyID_AvailableCompression
>> FormatList,NULL,&listSize,NULL);
>> QTGetComponentProperty
>> (ci,kQTPropertyClass_SCAudio,kQTSCAudioPropertyID_AvailableCompression
>> FormatList,listSize,listFormats,&listSize);
>>
>> QTGetComponentProperty
>> (ci,kQTPropertyClass_SCAudio,kQTSCAudioPropertyID_AvailableCompression
>> FormatNamesList,codecNamesListSize,&codecNamesList,&codecNamesListSize
>> );
>>
>> //I get the list perfectly fine with above code
>>
>> now when I do CloseComponent(ci); , it crashes complaining of bad
>> memory excess (EXC_BAD_ACCESS). If I dont do CloseComponent
>> everything goes fine. Am I missing out something here?
>
>It's probably a crash in CF due to over-release. You don't show your
>code for how you work with the FormatNamesList, but you should not be
>CFRelease'ing individual CFStrings in the CFArray. When you're done
>with the CFArray, you must call CFRelease(codecNamesList);
Speaking of this, this is an area that can also bite you in AudioUnit
development. In my case I was confused about exactly how CFStrings
in a CFArray were or were not retained, and this caused issues in
certain hosts that would take a CFArray of CFStrings (like the array
you pass back in GetParameterValueStrings), and possibly still use it
even after destroying the plugin.
It is vitally important to understand how the CFArrayCallBacks work
with regard to retaining elements of the array (if they're CFTypes).
For an array of CFStrings, you generally want to pass
kCFTypeArrayCallBacks, not NULL, for the CFArrayCallBacks param in
CFArrayCreate. When you do that, this is the behavior:
- Creating an array with items, or appending items to the array calls
CFRetain for the item(s).
- Calling CFRetain on the array only increments the retain count of
the array itself.
- Likewise, calling CFRelease on the array only decrements the retain
count of the array itself.
- When the CFRelease on the array causes the array's retain count to
go to 0, THEN it calls CFRelease for the contained elements.
If you pass NULL for CFArrayCallBacks, the contained items are not
retained or released, which can lead to unexpected behavior if the
contained items are actually CFTypes like in this case.
So, assuming you're using kCFTypeArrayCallBacks, like Brad says you
don't have to worry about releasing the elements of the array.
However, if you created new strings to populate the array to begin
with (i.e. CFStringCreateWithCString), you will want to CFRelease
those after adding them to the array, since these are separate copies.
CFGetRetainCount is useful in debugging these kinds of issues.
Jim
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Coreaudio-api mailing list (
--
Sandeep Chandna
98183-59325
_______________________________________________
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