I was testing some things with gdb with this code (it's a wrong code, i use it just for testing purposes):
#import <Foundation/Foundation.h>
int main (int argc, char **argv)
{
NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
int i = 1;
NSLog(@"Hi GDB, i is %@", i);
[pool release];
return 0;
}
Then i compile it : gcc -Wall -g -framework Foundation testGdb.m -o testGdb
, and i run it:
gdb ./a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-1518) (Sat Feb 12 02:52:12 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries ..... done
(gdb) run
Starting program: /Users/Tarek/Desktop/a.out
Reading symbols for shared libraries .++++....................... done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000000000000002a
0x00007fff82d7a0a3 in开发者_如何学Python objc_msgSend_fixup ()
(gdb) bt
#0 0x00007fff82d7a0a3 in objc_msgSend_fixup ()
#1 0x0000000000000000 in ?? ()
(gdb)
The strange thing is that ther's no name in (#1), the correct output would normally print NSLog(the cause of the crash) and main.
Thanks for helping to understand this strange behavior.
This answer is most likely applicable here as well.
Debug symbols have nothing to do with the problem -- GDB can unwind stack just fine without them (only unwind descriptors are necessary).
精彩评论