views:

280

answers:

2

Hi,

I am integrating OpenAL in my iPhone game from code I found in this post, but the compiler gave me an error on this line of code:
unsigned char *outData = malloc(fileSize);, so I changed it to this:
unsigned char *outData = (unsigned char*) malloc(fileSize);.

This got rid of the compiler errors, but seems to have thrown up two leaks:
Malloc 32 Bytes 0x505cb40 AudioToolbox SimAggregateDevice::CreateAggregateDevice(__CFString const*, __CFString const*, unsigned long&)

and
NSCFDictionary 0x505be30 64 AudioToolbox SimAggregateDevice::CreateAggregateDevice(__CFString const*, __CFString const*, unsigned long&)

Is this due to me changing the unsigned char line? I would be very grateful if someone could help me to remove these leaks.

A: 

I'm assuming you are using a .mm file instead of a .m (It's the only reason I can think that the compiler will yield an error without the cast). The change you made will have no effect on memory management, and will certainly not cause the leak. Are you freeing this data after using it?

Marcelo Cantos
Yes, later I call 'if (outData) { free(outData); outData = NULL; }'Having done another run with instruments, it is now giving me 10 leaks!! 5 of which are the same as above, and the other 5 are:'Malloc 32 Bytes 0x531b5d0 AudioToolbox CreateDictionaryForDevice(unsigned long)'
AptoTech
Sorry, I'm stumped. I can only surmise that some OpenAL resource isn't being released or closed or whatever. I don't know OpenAL well enough to suggest anything more.
Marcelo Cantos
Thanks for help anyway :), I guess il have to work on it some more. If anyone who does have OpenAL experience could help me I would really appreciate it.
AptoTech
A: 

I'm using custom code that I wrote myself, yet I'm getting all sorts of leaks as well. Let me know if you find anything out, and I'll do the same.

My current dump:

Malloc 48 Bytes     0x39225a0   48  AudioToolbox    SimAggregateDevice::CreateAggregateDevice(__CFString const*, __CFString const*, unsigned long&)
Malloc 32 Bytes     0x3922580   32  AudioToolbox    CreateDictionaryForDevice(unsigned long)
Malloc 32 Bytes     0x3922560   32  AudioToolbox    CreateDictionaryForDevice(unsigned long)
NSCFDictionary      0x3922520   64  AudioToolbox    CreateDictionaryForDevice(unsigned long)
Malloc 32 Bytes     0x3922500   32  AudioToolbox    SimAggregateDevice::CreateAggregateDevice(__CFString const*, __CFString const*, unsigned long&)
Malloc 32 Bytes     0x39224e0   32  AudioToolbox    CreateDictionaryForDevice(unsigned long)
Malloc 32 Bytes     0x39224c0   32  AudioToolbox    CreateDictionaryForDevice(unsigned long)
NSCFDictionary      0x3922480   64  AudioToolbox    CreateDictionaryForDevice(unsigned long)
NSCFArray       0x3922460   32  AudioToolbox    SimAggregateDevice::CreateAggregateDevice(__CFString const*, __CFString const*, unsigned long&)
Malloc 32 Bytes     0x3922420   32  AudioToolbox    SimAggregateDevice::CreateAggregateDevice(__CFString const*, __CFString const*, unsigned long&)
NSCFDictionary      0x3914580   64  AudioToolbox    SimAggregateDevice::CreateAggregateDevice(__CFString const*, __CFString const*, unsigned long&)

Still no fix. I'll keep you updated, though!

UPDATE:

It turns out, testing leaks against the iPhone simulator doesn't really give accurate results.

In any case, I would test leaks using the Simulator to filter out the standard 'oops', but really you should be testing leaks on your device. That's the only way to get real results for your app.

In my case, I tested my code again against my iPhone device and got no such dump as I posted. :)

Mark Sands