Re: 64-bit auval crash - Custom Unit
Re: 64-bit auval crash - Custom Unit
- Subject: Re: 64-bit auval crash - Custom Unit
- From: William Stewart <email@hidden>
- Date: Wed, 27 Jan 2010 17:24:13 -0800
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