Some tips and threaded discussion about using such tools as the leaks program and links to other DeveloperTools for the purpose at hand:

• Expand the disclosure triangle beside "Executables" in XCode and highlight your executable (In Xcode 2.5, double-click the executable and select the "Arguments" tab in the Info window. Be sure to add environment variables, not arguments.)
• The right pane shows the arguments you can pass your application at runtime. Click the + below Environment Variables. The new Name should be MallocStackLogging and the Value should be YES. Add an environment variable for MallocStackLoggingNoCompact?=YES as well.
• Compile and run your application
• open terminal and run "ps ax | grep -i yourappname
• The first column in the row for your app is its Process ID (pid). Make a mental note of it.
• type "leaks pid|more" in the terminal, where pid is the number of the Process ID
• You will get about a paragraph of information for each memory leak. The first line will usually give you the class name of the object that is being leaked. Make a note of it.
• Using enter or spacebar to scroll, scroll down to the end of the entry, where you will see a series of Objective-C class and method calls all jammed together. Somewhere in the last 5 to 10 method calls you can usually spot the name of a method you wrote in a class you wrote or subclassed.
• Examine that method in XCode.
• see RetainReleaseTips for information on how to manage memory. The basic rule is: If you alloc, retain or copy it, you need to release it.
• exercise the functionality of your app, checking back on leaks occasionally to see if it is leaking memory.
• When you get all the memory leaks out the leaks command should return 0 leaks.
• In addition to Leaks, there are ObjectAlloc and OmniObjectMeter.

NOTE: You should make sure you do not run leaks with NSZombieEnabled or it will look like everything is leaking!

-- TKinch

So you crashed in objc_msgSend(). Now what?

Most likely, you sent a message to an already-freed object. Or maybe your pointer is perfectly correct, but someone else mangled the object's contents - perhaps a buffer overrun in a nearby allocation, or use of a dangling pointer that once pointed to the memory now occupied by your object. Occasionally objc_msgSend() crashes because a memory error smashed the runtime's own data structures, but usually the trouble is in the receiver object itself.

Whether you're in the debugger or looking at a crash log, you can recover more information about the crash than just the backtrace.

Receiver and selector registers

objc_msgSend() stores the receiver object and the selector in CPU registers while it works. These values can help diagnose the problem.

The register names differ based on architecture and the objc_msgSend() variant used. This list is correct for Mac OS X Leopard and will probably remain correct for Snow Leopard.

Interpreting the receiver and invalid address

You can use the receiver's address and the invalid address that caused the crash to get some hints about the underlying problem. In a crash log, the receiver's address is in the Thread State using the register name in the table above, and the invalid address is listed at the top (usually something like KERN_PROTECTION_FAILURE at <invalid address>). In the debugger console, the invalid address is printed when the program stops, and you can print the receiver's address using the register name in the table above.

    Program received signal EXC_BAD_ACCESS, Could not access memory.
    Reason: KERN_PROTECTION_FAILURE at address: 0x00000001
    0x00090ec4 in objc_msgSend ()
    (gdb) p/x $eax
    $1 = 0x1

Usually, one of two things happens. The receiver address itself is bogus, and the invalid address is the same value (or 16 or 32 bytes away). Or the receiver address is reasonable, and the invalid address is the receiver's isa pointer. The latter is what usually happens if you try to use an already-deallocated object or someone else clobbered your valid object.

Look for special values like these in your crashes. Also look for nearby values; on some architectures, an invalid isa will cause a crash at isa+16 or isa+32 instead.

Not divisble by 16 - misaligned

malloc() returns 16-byte aligned blocks. If your receiver isn't 16-byte aligned, it probably never was a valid object pointer.

Top two and bottom two bits all set - malloc free list

After a block is freed, the memory allocator may write free list pointers into it. If you use a freed object after this, you'll see an isa pointer with the top two and bottom two bits all set.

All bits inverted - GC free list

Like the malloc free list case above, but caused by the garbage collector instead. In this case address looks bad, but ~address is more reasonable.

0xa1b1c1d3 - CF container

CoreFoundation containers use this value for deleted or empty items. Perhaps a freed object has been re-allocated as a container, or someone used a freed container that has been re-allocated as your object, or you read your pointer from a container that was simultaneously changed by some other thread and you don't have the right locks in place.

ASCII text

Perhaps a freed object has been re-allocated as a string, or someone used a freed string that has been re-allocated as your object, or some string operation has a buffer overrun. Use asciify to print these quickly in both endians. This one looks URL-related, for example:

% asciify 0x2e777777
###.www###
###www.###

Interrogating the selector

Compiler optimization means the call site pointed to by the second frame in the backtrace might not be the call that actually crashed. It's possible that call succeeded, and then that method made a tail call which was the one that crashed. Because of tail call optimization, the intermediate frame would be missing from the backtrace. We can use the selector register to determine what the real crashing call was.

A selector is a pointer to a unique C string. This may change in future OS versions, but for now it's handy for debugging. If you have crashed in a debugger, open the debugger console and run this, substituting the correct SEL register from the table above:

    (gdb) x/s $ecx
    0xa1029: "release"

Snow Leopard's crash reporter adds selector names to crash logs for you:

    Application Specific Information:
    objc_msgSend() selector name: release

1. From the crash log's Thread State, find the SEL's value using the register name in the table above.

       ecx: 0x000a1029

2. From the crash log's Binary Images, find the image whose address range includes the SEL's value. This will often be either the application itself or libobjc.A.dylib. If no image spans that address, give up.
       0x8b000 -   0x106ff7  libobjc.A.dylib ??? (???) <9b5973b7fa88f9aab7885530c7b278dd> /usr/lib/libobjc.A.dylib
3. Find a copy of the image that matches the one in the crash log. Use the UUID to verify the match.

       % dwarfdump -u /usr/lib/libobjc.A.dylib
       UUID: 26650299-C6EA-B1C8-52D6-072AC874D400 (ppc) /usr/lib/libobjc.A.dylib
       UUID: 9B5973B7-FA88-F9AA-B788-5530C7B278DD (i386) /usr/lib/libobjc.A.dylib
       UUID: D2A4E8E1-3C1C-E0D9-2249-125B6DD621F8 (x86_64) /usr/lib/libobjc.A.dylib

   This crash matches my installed libobjc.A.dylib for i386. If it's a system library, you may need the image from the OS version listed in the crash log. If it's your application, you did keep a copy of every version you shipped, right?
4. Calculate the SEL's offset into the image.

       0xa1029 - 0x8b000 = 0x16029

5. Print the C string in the image at that offset. Remember to specify the correct architecture.

       % otool -v -arch i386 -s __TEXT __cstring /usr/lib/libobjc.A.dylib | grep 16029
       00016029  release
   	    

方法三：


＋＋＋＋＋

NSLog definitely has its place in debugging. In a previous post I shared a version I wrote that skips displaying the date and object information, you can read more about the debug command I use on a regular basis here.

At some point, capturing debug statements to a file (versus the console) can be helpful to track down bugs. The good news is that you can continue to use NSLog (and/or the debug command from the previous post) by simply making a change to where stderr is directed.

For example, to re-direct stderr to a file “debug.txt” off the root of the system drive, follow these steps:

// Create OS specific path
const char *path = [@"/debug.txt" fileSystemRepresentation];

 
// Specify stderr writes to a file (truncating contents first) 
freopen(path, "w", stderr);

Each time you run your application, the contents of the file “debug.txt” will be truncated and all output written to the file. If you would like to keep a running tally of debug output across invocations of the application, you can change ‘freopen’ to append contents as follows:

// Specify stderr appends to a file
freopen(path, "a", stderr);

Ｑ：建一个基于视图的工程 然后build and debug 但是程序会自动退出调试状态  在debugger console下查看出以上信息 这是什么原因呀 新建的工程我可一点都没动呀我是在pc上装的mac

Ａ：XCode--Preferences...--Debugging--Symbol Lazy Options把下面那个选项(load symbol lazily)去掉,再设个断点就可以调试了