Auto-release Pools and Background Threads

Regarding Objective-C programming for MAC OS X and IOS:

(from )

Cocoa always expects there to be an autorelease pool available. If a pool is not available, autoreleased objects do not get released and your application leaks memory. If you send an autorelease message when a pool is not available, Cocoa logs a suitable error message. The AppKit and UIKit frameworks automatically create a pool at the beginning of each event-loop iteration, such as a mouse down event or a tap, and drain it at the end. Therefore you typically do not have to create a pool, or even see the code that is used to create one. There are, however, three occasions when you might use your own autorelease pools:

If you are writing a program that is not based on a UI framework, such as a command-line tool.

If you write a loop that creates many temporary objects.

You may create an autorelease pool inside the loop to dispose of those objects before the next iteration. Using an autorelease pool in the loop helps to reduce the maximum memory footprint of the application.

If you spawn a secondary thread.

You must create your own autorelease pool as soon as the thread begins executing; otherwise, your application will leak objects. (See “Autorelease Pools and Threads” for details.)

IOS / Mac OS X Link Problems involving symbols such as __ZTVN10__cxxabiv121__vmi_class_type_infoE

If linking produces undefined symbols involving the following:

  • __ZTVN10__cxxabiv121__vmi_class_type_infoE
  • __Znwm
  • __ZdlPv
  • ___gxx_personality_sj0
  • ___cxa_begin_catch
  • __ZTVN10__cxxabiv120__si_class_type_infoE
  • ___cxa_end_catch
  • __ZdaPv
  • __ZTVN10__cxxabiv117__class_type_infoE
  • etc.

It means you’re NOT linking with the C++ runtime libs.  To link with the C++ runtime libs, include an empty source file having a file extension of “.cpp”.   For more information, see the IOS Objective-C linking notes

XCode Linker will automatically choose dylib over static libs

A note about building (linking) a project in XCode:

If a static lib’s corresponding dylib is in a library search path during linking, Xcode will link to the dylib instead of the static lib.

The solution is to move the dylib somewhere else.
(from a Chilkat customer) “I created chilkat-9.2.1-macosx-10.5/lib/dylib and moved the dylibs into it.  Since my library search path in the project settings is not recursive, Xcode can’t find the dylib and links to the static lib.  It’s quirky and slightly hackish but you might want to consider structuring your download the same way to prevent other Xcode users from running into the problem.”

Note: The next version of the Chilkat Objective-C libs will be structured such that the dylibs and static libs are in separate directories.  Hopefully this will prevent this pitfall (where a user *thinks* the static lib is being linked, but in fact XCode is linking against the dylib).