Re: 64-bit auval crash - Custom Unit
Re: 64-bit auval crash - Custom Unit
- Subject: Re: 64-bit auval crash - Custom Unit
- From: Blue Cat Audio Dev <email@hidden>
- Date: Thu, 28 Jan 2010 14:16:14 +0100
Thank you for your answer.
I might be missing something here, because we indeed use the method
described below to fill the parameter name and do not use any specific
pointer arithmetic. It's when we set the unit to
kAudioUnitParameterUnit_CustomUnit and the unitName filed that the 64
bit validation crashes. Here is an example of the code used to fill
the parameter info strings:
CFStringRef
nameStr=CFStringCreateWithCString(kCFAllocatorDefault,"Dummy
Name",kCFStringEncodingUTF8);
AUBase::FillInParameterName (outParameterInfo,nameStr , true);
///> for some reason, auval 64 bits fails if unitName is not NULL
outParameterInfo.unitName=CFStringCreateWithCString(kCFAllocatorDefault,"Dummy
Unit",kCFStringEncodingUTF8);
outParameterInfo.unit = kAudioUnitParameterUnit_CustomUnit;
///< end code crashing 64 bits
Is there anything wrong with it? Maybe the history behind this struct
is not clear to me, but it looks like the following code (taken from
the AUBase FillName function) is writing at the location of the
unitName CFString pointer as well, right? (clumpID is defined after
unitName)
CFStringGetCString (inName, ioInfo.name, offsetof
(AudioUnitParameterInfo, clumpID), kCFStringEncodingUTF8);
Is this because the the "unitName" field is deprecated? As far as
header versions are concerned we are using the latest version from the
XCode 3.2 SDK.
BTW have you noticed something odd in the returned struct that makes
you think it's invalid?
Regards,
W.
Blue Cat Audio
Quoting William Stewart <email@hidden>:
Hi W.
So, I've downloaded the AU and looked at it, and this is a bug in your
code and you should fix this before you release the audio unit. I'm
posting the response to the list in case other people have this problem.
Here is what the struct looks like:
typedef struct AudioUnitParameterInfo
{
char name[52];
CFStringRef unitName;
UInt32 clumpID;
CFStringRef cfNameString;
AudioUnitParameterUnit unit;
AudioUnitParameterValue minValue;
AudioUnitParameterValue maxValue;
AudioUnitParameterValue defaultValue;
UInt32 flags;
} AudioUnitParameterInfo;
In a 32bit world, it will look exactly the same in terms of the bytes
it uses to the way this struct looks in Leopard or Tiger. In the 64bit
case, the struct will be a different size than in the 32 bit case,
because the pointers of the contained members are of course 64bit
pointers, not 32bit, so the offsets of clumpID for instance, will be at
a different byte offset than in the 32bit case.
In AUBase, you have this method (to fill in the struct):
static void FillInParameterName (AudioUnitParameterInfo& ioInfo,
CFStringRef inName, bool inShouldRelease)
{
ioInfo.cfNameString = inName;
ioInfo.flags |= kAudioUnitParameterFlag_HasCFNameString;
if (inShouldRelease)
ioInfo.flags |= kAudioUnitParameterFlag_CFNameRelease;
CFStringGetCString (inName, ioInfo.name, offsetof
(AudioUnitParameterInfo, clumpID), kCFStringEncodingUTF8);
}
This is safe for both 32 and 64 bit architectures.
In auval, it gets the name of the parameter 52 bytes into the struct,
which is where unitName is defined to be. It will of course read either
a 32 bit or 64 bit value from that location depending on which arch is
being executed.
I think that what you are doing is something different with the name of
the parameter (perhaps you are only storing a 32bit value for the unit
name)?
There is some history to the way we have dealt with this struct, and so
if you compiled against an older version of the headers, or had written
your own method for storing the unitName, then you might not have this
in a completely safe manner for dealing with both 32 and 64bit archs.
Thanks
Bill
Quoting William Stewart <email@hidden>:
This isn't a known issue. Can you send me the AU so that I can have a
look at it?
On Jan 22, 2010, at 2:07 PM, Blue Cat Audio Dev wrote:
Hi,
I have been trying to validate 64 bits AU plugins for Logic 9.1,
but auval crashes as soon as one of the parameters uses a Custom
Unit (kAudioUnitParameterUnit_CustomUnit set and non-NULL
unitName). You can see the log and stack below.
If the unitName field of the AudioUnitParamInfo struct is NULL
for all parameters, auval does not crash anymore and the plugin
can be validated. This problem does not occur for our 32 bits
plugins, and the 64 bit plugin is running fine in logic despite
this auval crash (even the generic "controls" view works,
displaying appropriate units).
I have tried both static and dynamically allocated CFString for
unitName, it has no effect: auval keeps crashing.
Is this a known issue? Is there anyway to avoid this problem
apart from suppressing custom units from the parameters?
Regards,
W.
Blue Cat Audio
=> auval log extract:
--------------------------------------------------
PUBLISHED PARAMETER INFO:
# # # 9 Global Scope Parameters:
validation result: crashed validation
--------------------------------------------------
=> stack
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 com.apple.CoreFoundation 0x00007fff803a2b40 CFRelease + 112
1 auvaltool 0x0000000100005582 0x100000000 + 21890
2 auvaltool 0x0000000100005af6 0x100000000 + 23286
3 auvaltool 0x000000010000cf63 0x100000000 + 53091
4 auvaltool 0x00000001000015de 0x100000000 + 5598
5 auvaltool 0x0000000100001c7f 0x100000000 + 7295
6 auvaltool 0x0000000100000c1c 0x100000000 + 3100
_______________________________________________
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
_______________________________________________
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