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'.
Related
In an Xcode project, how can I write any Swift codes that crashes the Application on startup once it’s launched/run on the simulator or device?
You can follow app lifecycle events in your UIApplicationDelegate. For example application(_:didFinishLaunchingWithOptions:)) is called, when the app started and a little time before it's visible. You can put the crashing code there.
There are a few ways to crash the app. One of them is to call fatalError().
I have developed an app for the iPhone and everything is going well. Today i decided to prep it for the upcoming iOS 7 launch, and the app worked as intended until I tried it on my iPhone 5. Whenever it crashes it throws some exc_bad_access codes.
It doesn't crash in the simulator or on my iPad which is running iOS 6.1.
I hope you guys can help me.
Btw, i get different exc_bad_access codes every time, but this is one of them.
http://gyazo.com/43716488eb120e44e74f76cd4d659076
You have thread-related race conditions. Note how it's crashing in thread 7? Race conditions will express themselves differently on different hardware since the timing can be dramatically different.
tableView:cellForRowAtIndexPath: is a UIKit method that must run on the main thread. In your case, it's running on thread 7, which is itself probably the cause of your problem. I suspect you're doing something like calling reloadData on a background thread.
Note that you're also directly accessing your ivars rather than using accessors. That tends to make threading problems harder to track down and manage. You should always be using accessors except in init, inside of accessors, and in dealloc.
I have a tab bar app with 4 tabs and nothing spectacular in the code.
All simulator testing is fine, there are no crashes with the app, everything works great, there are no warnings or errors shown up in Xcode (I am using Xcode 4.2 and the app uses storyboarding).
When running 'analyse', there are no leaks, errors or potential leaks in the code.
When running 'leaks', no leaks are listed, and I can load, reload, swap between tabs, etc, and all is fine.
When I run this on an iPhone, though, lots of leaks show up!
Some of them seem to be in code that is all released and looks fine, and all validates fine within Xcode.
Why is this different running on the phone from the simulator, and how can I find and debug leaks that dont show up when running leaks on the simulator?
First, by limiting the inspection range (with the left and right range buttons) to the area where leaks occur, you can inspect a smaller area. Then, by selecting some useful checks from the Call Tree on the left hand side, like Show Obj-C only, Hide Missing Symbols, etc.. then you'll get a lot more useful info from the Instruments. After that, click on one of the lines related to the leak, open Extended view and start examining your call stack. Also, as far as I could remember, double clicking on a leak line can take you to the source code where the leaked object is allocated. Be careful here, because it does not show where the leak happens, it shows where the leaked object is allocated. So, you should follow what happens to these objects, then.
And about the difference between simulator and the device, you can check this SO question.
Hope these help!
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.
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.