I have some code that returns a struct containing 2 objects (declared as id).
When trying to use one of the objects I get an EXC_BAD_ACCESS and the app crashes. This only happens on the device (ipad) not in the simulator.
I have set NSZombieEnabled to YES, however no information is written to the console.
I don't know if it's a problem that I'm using a workspace in Xcode 4, one project for my app, and another that builds a library which is used in my app. The EXC_BAD_ACCESS is occurring in the second project, so I don't know if NSZombieEnabled will apply to the second project?
How do I solve this? Especially as I it only happens on the device (even goes as planned on the simulator), and it is in the second project?
EDIT: This is the method where the EXC_BAD_ACCESS occurs, on line 62, on sortRange.lower –
NSZombieEnabled only works on the simulator, not on the device, so it's probably hiding the problem. Run Product > Analyze (⇧⌘B) for clues. It's harder to say more without looking at the code. As Mihai says, your objects are probably over released, which is the most common cause of EXC_BAD_ACCESS.
It seems that one of your objects is autoreleased before you are trying to access it. As the iPad has less memory than the computer you are running it on it get's released faster so that's why it's not available. Try NSLog both objects just before the line you are getting the error and see wich one of them is the problem and than trace back to it's origin and retain it somehow. Also don't forget to release it after you are done using it. Some example code would be useful.
Related
I'm at a complete loss with a memory bug. This issue only happens on the device and not the simulator. It also only happens when the app is loaded for the first time on the device. If I close the app and relaunch it the issue does not preset itself. This is the error I'm getting
-[CFString retain]: message sent to deallocated instance 0xfd5a2f0
I've tried everything to attempt to figure out what the released string is. Please help me figure out what the released object is when running on the device and not the simulator! Thanks in advance!
UPDATE:
I still do not have a solution but I have confirmed the app will crash consistently on the line of code where I set a frame and the above error shows. If I comment this code out the app will pass this point but may crash at other strange spots. I can't even begin to determine where the crash is originating.
CGRect frame = CGRectMake(27, 96, 265.0, 50.0);
someAcct.frame = frame;
I'm so confused by this since this is not a string. Any ideas?
UPDATE 2: This issue is directly related to the NSUser Defaults being synchronized. This seems pretty random but this is causing the issue. Any Help?
UPDATE 3: The problem has been solved as of a week ago. This was in fact due to a string being inaccessible. A string was passed to a method, that method then did work and passed data to another method and so on. Until finally the data was to be written to user defaults and a local plist contained within the documents folder. All of a sudden the app would crash at very strange places like the above consistently even though those places had nothing to do with a string. I was baffled and after playing with it for a very long time I decided to head over to the .h file and go through each string one at a time by making sure each were synthesized in the .m file and that self.stringName was applied throughout the .m file. After spending an hour on this I finally found the string that was to blame and the issue is now resolved. Using self.stringName allows the memory to be found and avoids these obscure and highly confusing application crashes. Thanks to everyone for all of the suggestions and tips!
To help you with tracing it down, could you try putting NSLog at the start of your didFinishLaunching() method, somewhere in the middle and at the of the didFinishLaunching().
Then also could you push a NSLog in the viewDidLoad() of the first view controller your app shows. For example, if you're using a tab bar interface, then a NSLog in the first tab's root view controller.
You can use NSLog(#"step 1"), NSLog(#"step 2"), NSLog(#"step 3") ... to organise the output so you know where the code managed to reach up to before it crash, rather than NSLog(#"I am here").
The problem is of retain count. Refer mememory management and check u r not missing something.
Don't forget to turn on NSZombieEnabled.
One reason can be due to the iOS compatibility.Check if your device and the simulator are using the same iOS.Try working the simulator on the same version of OS as your device and change the release of the string accordingly.
My app is crashing using iOS5 and iOS4.3 iPhone simulators in Xcode 4.2, the stack trace shows BAD_ACCESS signal in [FlurryAPI stopBackgroundTask] method.
While in the iOS4.3 simulator the app is only crashing when sending the app to background, in iOS5 is crashing always.I am attaching a picture of the debug navigator showing the thread where the BAD_ACCESS is happening.
On the other hand the app is working fine using a real device.
Any ideas of how can I get more information of what is going on and why this is happening?
I've worked around this issue by adding the following to didFinishLaunchingWithOptions
#if TARGET_IPHONE_SIMULATOR
[FlurryAnalytics setSessionReportsOnPauseEnabled:NO];
#endif
Flurry analytics does not run other than main Thread. It might crash on background thread.
It looks like you have a zombie - you have a situation where you're using code after you've released it. The retain count reaches zero, so the system dealloctes and re-uses the memory, then you make a change through the original reference. Now you have two different references to the same memory, each of which expects a different object to be there. In your case, one of the references is within flurry.
The reason for your device/simulator differences is the different memory allocation schemes the two architectures use - the simulator seems to re-use memory very aggressively.
Enable NSZombie and run in the debugger. If you're lucky, it will give you the object and the point it's used after deallocation.
Enable NSZombie: Menu 'Product', 'Edit Scheme...' 'Run' page, 'Diagnostics' tab, tick 'Enable Zombie Objects'.
I know people here can help me with my problem in memory warnings on my app. I have multiple objects added to my Nib file, connected them to multiple IBOutlets and release these outlets on my viewDidUnload and dealloc method, I also set them to nil, but it still keeps on crashing after the "Received Memory Warning = Level 1" error message. I used NWPickerField for my objects in Nib files.
http://cocoacontrols.com/platforms/ios/controls/nwpickerfield
I just hope anyone here have tried using this :) thanks and Cheers!
If you're crashing when you receive the memory warning, that usually means that something gets deallocated, but it's pointer isn't set to nil, you try to access it, and Crash!
Errors like this can be hard to track down. A few types:
You can play around with XCode instruments (using Build&Profile in XCode 4) - specifically the Zombies one, which 'keeps dead objects around (as Zombies)', but let's you know when they get accessed.
Another useful one is a watchpoint. Once the simulator is running, right click a variable in console, and say 'Watch this address'. Then any line of code that causes a change to that memory location will cause a breakpoint when it occurs.
Another thing to try is just to run through all your ivars, inits, and deallocs, and make sure you really did get every case.
As you mentioned in your question.
I also set them to nil,
Do the proper memory clean up. by first calling release function or delete operator then assign the object with nil.
i populate uipicker's datasource from array built with sqlite database stored data. everythiongs works fine.. for a little while. after 6-7 spinnings, the picker freeze, and I get EXC_BAD_ACCESS. debugger indicates the program stopped in the main () function.
so, how could this happen? working for a while, and then, suddenly exit like that?
thanks
Somewhere in your application, you have over-released an object. When the application tries to access it again, very likely to release it (from an autorelease pool), it crashes. The problem may be completely unrelated to your picker.
Suggestion: try adding NSZombieEnabled YES to your executable's environment variables.
I've developed my application using my 3G device to test with. Upon giving this to a friend to test, he's noticed that it crashes..I've had a look at the crash log, but it's not much use except for the "EXC_BAD_ACCESS" statement after a few memory warnings.
On my device, I can use the imagePicker lots, and each time a photo is taken I get a memory warning, but this doesn't cause any problems.
On my friend's device (also a 3G), after a couple of images chosen from the camera, the app crashes.
So, my question is.. I think something is being deallocated because of the memory warning - but only on my friend's device, and then after deallocation, it's trying to be used again. How can I find out what object is being called? I can't use NSZombies because this is a remote (beta) device.
Help please!
Also if anyone has any ideas why my device can pick image after image without any problem and his can't...that would be most helpful
Thanks!
EDIT: New discovery.. I'm getting this error message too: KERN_PROTECTION_FAILURE which I understand to be something to do with data access. The crash seems to happen right after I save the image got from the UIImagePicker. Any ideas?
You may be over-releasing something. If you're running Snow Leopard, run the Static Analyzer (Cmd-Shift-A) and look for memory errors.
The fact that it crashes after a memory error suggests that a UIViewController has released its view. Do you have any UIViewControllers that observe NSNotifications, or otherwise might change their IBOutlets while they are off-screen? This is a common cause of this kind of crash. Make sure you're correctly memory managing your IBOutlets. UIViewControllers should never mess with their IBOutlets (or their UI components at all) when they are off screen. Even if you don't make this mistake, if you're not implementing things as noted in the above link, you can still crash after memory warnings.
MemoryWarning was a pretty good idea, and things have improved, but Apple still hasn't quite cooked all the issues around how it plays with UIViewController. The developer still needs to be very careful.
You should have your friend come to your computer and run it with NSZombieEnabled. That's the best way to debug these issues.