cocos2d for iPhone

A fast, easy to use, free, and community supported 2D game engine

1. 

   Metric
   Member

   So, I was testing with the leak tool and noticed that multiple objects are leaking at the very beginning during initialization. However, none of them are my objects that I have created.

   I am just curious if this is common for the iphone sim and other developers.

   Here is a list of what I have found:
   -Malloc 208 Bytes: 0x3c83b80, 0x3c83a30, 0x3c838d0 - Source: AudioToolbox: RegisterEmbeddedAudioCodecs()

   -Malloc 176 Bytes, 0x6868e30 - Source: AudioToolbox: RegisterEmbeddedAudioCodecs()
   -Malloc 128 Bytes, 0x3c7f7b0 - Source: AudioToolbox: RegisterEmbeddedAudioCodecs()
   -Malloc 224 Bytes, 0x3c7c330 - Source: AudioToolbox: RegisterEmbeddedAudioCodecs()
   -Malloc 208 Bytes, 0x3c7c1e0 - Source: AudioToolbox: RegisterEmbeddedAudioCodecs()

   -Malloc 48 Bytes, 0x685d790 - Source: AudioToolbox: SimAggregateDevice::CreateAggregateDevice

   -Malloc 32 Bytes, 0x685d770 - Source: AudioToolbox: CreateDictionaryForDevice(unsigned long)
   -Malloc 32 Bytes, 0x685d750 - Source: AudioToolbox: CreateDictionaryForDevice(unsigned long)

   NSCFDictionary 64bytes, 0x685d710: -Malloc 32 Bytes, 0x685d770 - Source: AudioToolbox: CreateDictionaryForDevice(unsigned long)

   --- it just goes on a little further for the audio toolbox with more createdictionaryfordevice and SimAggregateDevice.

   Then it gets to:

   Malloc 128 Bytes, 0x68360f0 - Source: CoreGraphics: open_handle_to_dylib_path

   Malloc 128 Bytes, 0x6809b70 - Source: libGFXShared.dylib: gfxPluginConnectAll

   Malloc 128 Bytes, 0x6809b20 - Source: OpenGLES: eagl_init_once

   Is this normal for the simulator? I find it a little odd if no one else has noticed this, because each one of these has to do with a standard iPhone library like AudioToolBox, CoreGraphics, libGFXShared.dylib, and OpenGLES.

   Tested with the latest XCode and 3.1.2 iPhone Simulator in Debug Mode.

   Posted 2 years ago #
2. 

   Poltras
   Member

   The simulator has bugs related to singletons and llvm stuff that are incorrectly reported by Instruments. Always check your leaks on the device itself.

   Posted 2 years ago #
3. 

   Metric
   Member

   Thanks Poltras, I had a feeling it had to do with the Simulator.

   Posted 2 years ago #
4. 

   Steve Oldmeadow
   Administrator

   You'll get similar leaks reported by the Leaks Instrument on the device too if you use OpenAL. However, how do we know the problem isn't with the Leaks Instrument? When I was working on CocosDenshion I found that if I delayed the initialisation of the OpenAL context then the leaks were not reported which indicates to me the problem is more with the Leaks Instrument.

   Also why worry about such small one off memory allocations? To me a memory leak is an on going problem that will eventually eat up all the memory. If you are worried your app will get rejected - my understanding is the only technical analysis done of your app is to see if it links to any private libraries.

   Posted 2 years ago #
5. 

   Metric
   Member

   Isn't Cocos2d and CocosDenshin technically a private library when compiled as a static library? Is it not considered a private library, because of being open source?

   I believe those are very reasonable questions, because of Apples pain in the ass approval process.

   Posted 2 years ago #
6. 

   PhilM
   Member

   'private libraries' refers (in this case) to the other API's Apple use for their own apps, that they don't allow us developers to access.

   You have to go through a few hoops to gain access to them in the first place, so you know if your using them
   ; )

   Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.