Optimize your Autorelease pools with the following environment variables
NSAutoreleaseHighWaterMark
Default: 0
If set to X, autorelease pools will print a message if more than X objects accumulate in the pool
NSAutoreleaseHighWaterResolution
Default: 0
If set to Y, a message is logged for every Y objects that accumulate in the pool beyond the high-water mark (X)
Monday, December 14, 2009
Thursday, December 10, 2009
NSAssert
Vicente Gable:
The NSAssert() function is unreliable, and therefore dangerous. Plain-old assert() is a better choice...
Rob Napier:
Broad use of NSAssert() will not turn ObjC into Eiffel, but it's still a fairly good practice as long as you keep in mind how it's actually implemented and what it's doing. Things to keep in mind about NSAssert():...
The NSAssert() function is unreliable, and therefore dangerous. Plain-old assert() is a better choice...
Rob Napier:
Broad use of NSAssert() will not turn ObjC into Eiffel, but it's still a fairly good practice as long as you keep in mind how it's actually implemented and what it's doing. Things to keep in mind about NSAssert():...
Use NSAssert(…) during development.
But set NS_BLOCK_ASSERTIONS pre compiler flag for release.
But set NS_BLOCK_ASSERTIONS pre compiler flag for release.
Labels:
NSAssert
Tuesday, December 8, 2009
Kamocsay Lajos: how to debug EXC_BAD_ACCESS on iPhone
Itt van az egesz, de roviden a lenyeg:
If you set the NSZombiEnabled environment variable, the Objective C runtime will leave a dummy object behind for every deallocated object. When the zombie object is called, execution stops and you can see the message that was sent to the object and the call stack that tells you where the message came from (it doesn’t tell you where you over released the object, but knowing where the object is called from should get you pretty close to the problem.)
If you set the NSZombiEnabled environment variable, the Objective C runtime will leave a dummy object behind for every deallocated object. When the zombie object is called, execution stops and you can see the message that was sent to the object and the call stack that tells you where the message came from (it doesn’t tell you where you over released the object, but knowing where the object is called from should get you pretty close to the problem.)
Labels:
debug,
EXC_BAD_ACCESS,
NSZombiEnabled
Friday, December 4, 2009
Subscribe to:
Posts (Atom)