Hi,
We developed a game using cocos2dx framework. Our app crashed in following line (not all the time, around 1 in 20 times). Can you please help us to identify the issue.
CCUserDefault::sharedUserDefault()->setIntegerForKey(“NetWorth”, netWorth); CCUserDefault::sharedUserDefault()->flush();
You should step into the following function, and check if there is a problem with copying the value into the buffer or saving the value to the file in setValueForKey(pKey, tmp);:
void UserDefault::setIntegerForKey(const char* pKey, int value)
{
// check key
if (! pKey)
{
return;
}
// format the value
char tmp[50];
memset(tmp, 0, 50);
sprintf(tmp, "%d", value);
setValueForKey(pKey, tmp);
}
Try to find variable using the memory address, which will be printed out in the stacktrace:
Queue EXC_BAD_ACCESS UNKNOWN at 0x006a5936
Print out the address of your netWorth variable and also look at the address used in setValueForKey(pKey, tmp);.
As your code crashed in 0 CoreFoundation __CFTypeCollectionRetain + 7, it is a sign, your variable is destroyed, before giving the CF code a chance to use it.
Does your code use threads for saving/reading to CCUserDefault?
This is the code for setIntegerForKey function. netWorth is a local int variable. not sure why it could get release. we are not using separate thread. Entire app runs in one thread. Can you please let me know how I can make sure netWorth variable is not releases?
You can make it persistent, if you are allocating it on the stack/heap and keep a reference on it, but this is not the problem. It’s just a local variable, as you stated.
It seems the compiler does not like networth to be a long int, but copying the value to an int.
long int is 8 bits and int is 4 bits on 64-bit systems. Assigning long int to int is compiler/undefined behavior.
Can you try to change it to an int and test it?
You should also breakpoint at [[NSUserDefaults standardUserDefaults] setObject:[NSNumber numberWithInt:value] forKey:[NSString stringWithUTF8String:pKey]]; and see why it is crashing. See if the value is valid.