Message causes EXC_BAD_ACCESS (updated with new info)

This is my code where I'm getting the error above; the line causing the error is the call to "addRecordToDatabase. If I remove the call to the method and substitute the actual code that was in the method, the error goes away. What is causing this?

// do something useful with the data (like, enter it into the d/b)
    SQLiteDB *db = [SQLiteDB sharedSQLiteDB];
    [db addRecordToDatabase:(NSString*) symbol.data andTypeName: (NSString *) symbol.typeName];


//---------------------    addRecordToDatabase    ----------------------|
- (void)addRecordToDatabase:(NSString*)data andTypeName: (NSString *)typeName  {

    NSString *insertCommand = [NSString stringWithFormat:@"INSERT INTO s64Data (CARD_ID, CARD_NAME, CODE_VAL) VALUES ('/%s', '/%@', '/%s')",
                           data, @"Test", typeName];

    if(sqlite3_open_v2(cDatabasePath, sharedSQLiteDB, SQLITE_OPEN_READWRITE, NULL) == SQLITE_OK) {


    }
}

and this is the console output:

The Debugger has exited with status 0.
[Session started at 2011-04-30 06:14:36 -0700.]
GNU gdb 6.3.50-20050815 (Apple version gdb-1510) (Fri Oct 22 04:12:10 UTC 2010)
Copyright 2004 Free Software Foundation, Inc.开发者_JAVA百科
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 "--host=i386-apple-darwin --target=arm-apple-darwin".tty /dev/ttys001
Loading program into debugger…
sharedlibrary apply-load-rules all
Program loaded.
target remote-mobile /tmp/.XcodeGDBRemote-778-28
Switching to remote-macosx protocol
mem 0x1000 0x3fffffff cache
mem 0x40000000 0xffffffff none
mem 0x00000000 0x0fff none
run
Running…
[Switching to thread 11779]
[Switching to thread 11779]
continue
2011-04-30 06:14:50.183 PointPeek[137:707] error: (null)
Program received signal:  “EXC_BAD_ACCESS”.
warning: Unable to read symbols for /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.3.2 (8H7)/Symbols/Developer/usr/lib/libXcodeDebuggerSupport.dylib (file not found).
(gdb) 

This line

[db addRecordToDatabase:(NSString*) symbol.data andTypeName: (NSString *) symbol.typeName];

makes no sense. Parameter types go in method declarations, not method calls.

[db addRecordToDatabase:symbol.data andTypeName:symbol.typeName];

would make more sense.

Well, what have you tried doing? This should be a pretty simple thing to debug if you work through it methodically.

Questions:

1. Is db defined? Is it a "real" instance of SQLiteDB or not in some way corrupt? Is it in a normal state or did it return some error state?

2. What are the types of symbol.data and symbol.typeName? Do you really need to cast them to NSString?

3. What are the values of of symbol.data and symbol.typeName? Are they sensible and non-nil?

4. Which line of addRecordToDatabase:: causes the crash?

5. If it's not the first line, what is the value of insertCommand?

My guess is that your crash is because you pass in an NSString and then tell [NSString stringWithFormat:] that those same types are char* (the %s). You need to be using %@ for objects. An NSString is not the same as a normal C string. The results are difficult to predict as it's likely dependent on the contents of the stack. A crash sounds likely...

EXC_BAD_ACCESS is a symptom of bad memory management. One of the objects you're trying to access, (db, symbol, or possibly symbol.data), could have been removed from memory or not properly allocated initially.

You can find out which one by setting a breakpoint at the line in question and debugging. My money is on symbol. So, at the point where symbol is created, try adding a retain call, something like:

Symbol *symbol = [Symbol symbolWithData:blah] retain];
... (make db call here)
[symbol release];

A couple other suggestions:

1. Make sure you have XCode setup so breakpoints are tripped any time an NSException is thrown.
2. Use NSZombiesEnabled as described in this Stack Overflow post.