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.
Related
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 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'm debugging my app with the simulator. And for some moment in concrete situation the app gets mimimized. I think there is some problem in my code (Most likely some variable is not initialized, because sometimes everything works) . But how can I catch this moment.
In xcode is still written that the program is running and I can put breakpoints and the will trigger.
And if i will reopen my application it will continue working...
When using device the are no problems too...
How can i catch this moment and pause the program to view a callstack.
EDIT
I Think the problem is here:
Objective-c singleton object does not working as expected
You could try catching it in the - (void)applicationDidEnterBackground:(UIApplication *)application-methode in the app delegate, at least then you will see specifically when it happens.
This just started happening when I tested on my iPad using the new 4.2.1 firmware using the iOS 4.2 final SDK, however I've changed a lot of code since the last time I tested on my device so I can't be 100% sure it's 4.2.1 related though it seems very likely. I was previously testing on 4.2 beta3 with 4.2 beta3 SDK with no problems.
I have a view that does some Quartz 2D drawing. Every time I call [self setNeedsDisplay] on it to update the drawing, the application crashes with a Signal 0. I've never had a problem with this before and was always using that call to redraw the view without issue.
Has anyone run into this before or has any info on what the cause could be? The crash is happening before drawRect: is called, so I'm not sure how to debug this.
It does not crash in the simulator, only on the actual device.
No crash logs are generated on the device and the exact error that is displayed in the debugger is this:
Program received signal: “0”.
Data Formatters temporarily unavailable, will re-try after a 'continue'. (Unknown error loading shared library "/Developer/usr/lib/libXcodeDebuggerSupport.dylib")
Also, before anyone suggests that it's an issue with using too much memory as signal 0 errors often are, the app is using only 1.4mb of ram when the crash happens (viewed in Instruments) and I don't see a big spike of allocations or anything before it crashes. It crashes with just over 1.4mb used.
Update: I've been working on this more, here's what I've found so far.
There seem to be some issue with the 4.2 final SDK and iOS 4.2.1 but they don't seem related to this particular issue.
I've downgraded to 4.2 beta 3 that was previously working for me, and it is still crashing the same way
If I don't override the drawRect: method in my class and I call setNeedsDisplay is DOESN'T crash.
If I override drawRect: even if I keep it empy (just calling [super drawRect:] or even leaving it completely empty) it DOES crash.
So for some reason, just implementing drawRect: at all is causing this problem. It makes no sense though as I've implemented this code this same way since I started this project and am only now experiencing this issue.
Update: It turned out to be a memory issue after all related to the size of the view that I'm doing the drawing in. Although the Instruments tool seems to not be displaying it for some reason, according to this post: iPhone + UIView. Enormous memory consumption during drawRect. Any strategies for reducing this? when using setNeedsDisplay: on a large view there is a huge memory spike and the only real way to fix it is to use smaller tiled views and draw in each separately.
I removed a bunch of images from my scrollview and was able to see the memory warnings without the crash. I found if I lower the size of my drawing view in the scroll view, I no longer get memory errors. I had the drawing view at almost 4000x4000 before. Lowered it to 3000x2000 and no more crashes.
Now the issue for me is I need one contiguous drawing view, due do the nature of what I'm drawing I'm not sure it's possible to tile it. But that's a question for another post.
Try this Other Answer/Solution
Basically it is likely a memory problem.
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.