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.
Related
I have a working iPhone app using SDK 4.0. It shows no leaks in the 'Instruments' tool, and I am fairly convinced that the code does not have any memory leaks.
I then tried to add iAds to the app, and it started showing memory leaks. In order to nail down the problem, I removed all additional code.
All that is left is an added AdBannerView to the .xib file (without doing a single modification to the working version of the code without iAds). This shows memory leaks.
Every time the view loads, the 'Instruments' tool shows 5 leaked blocks of 16 bytes each, with the Responsible Library 'Foundation', and Responsible frame
[NSCFString copywithZone:]
Further running the app gives me leaks from the Responsible library 'iAd' (2 leaks of 48 bytes each), and the responsible frame:
[AdBrandingFrame initWithFrame:]
Further, I also get 48 byte leaks with the responsible library 'UIKit' and responsible frame
-[UIView _createLayerWithFrame:]
Since there is absolutely no addition to my working non-leaking code, except an added AdBannerView to the .xib file, I wonder if it is Apple's code that causes the leak. Although the leak is relatively small, I would like to iron it out. I understand that there is a possibility that a leak shows up even though there may not be one (the pointers might still be held by the OS in some way that Leaks does not know about - It would be great to know if this is the case).
So I had two questions:
1) Is there any chance the problem is actually my code, and the leak for some reason only shows up after adding AdBannerView? If there is such a possibility, I would run another thorough code test.
2) If this is a problem with Apple's code and any of you have encountered this, are there any workarounds you have found?
Any help would be greatly appreciated. Thanks!
I just had the same issue. I think this has been fixed in IOS 4.1
When I test in 4.0 I got a couple leaks "NSCFString copyWithZone"
When testing in 4.1 all is good.
I am getting a lot of strange EXC_BAD_ACCESS crashes on the iPad that only happen on the device and not in the simulator. I am assuming that they are somehow memory related, but I am not sure. They all happen with image context related functions.
One strange example is using CGImageCreateWithImageInRect. For example, if i run through a bunch of UIImages and crop them with CGImageCreateWithImageInRect, it will always crash at specific arbitrary sizes. Like, if I crop them all to 200x200, it crashes out after processing 12 images. If i crop them to 210x210, it works no problem.
The EXC_BAD_ACCESS happens inside of "memmove" called from "CGBlt_copyBytes". That is all the debugger shows me strangely enough. I can't see the callstack going up to any of my methods.
All of this works fine in the simulator!
I know this is all very vague, but if anyone has any ideas, they would be greatly appreciated.
Start by doing things like checking for zombies, and running clang (Build & Analyze) to see if you have memory management issues. I think you'll need to post more code, because this does sound like memory stomping.
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.
My GUI for an iPhone app uses numerous UIViews. The user "flips" through these views when they tap a button to go forward or backward. The views are stored offscreen and are added to an actual view only when the program needs to display it.
During the flip process, the program tells the parent view (a uiscrollview) to remove any existing subview using the removeFromSuperView method, and then adds the new subview, which is the new page that the user should see.
However, after several repeats of this process on the device, the program crashes with gdb exit status 101, which I found is caused by an out of memory error.
I tried diagnosing this problem using the Leaks tool, but to no avail. There is only 1 or 2 small memory leaks and the total mem usage on the device by the program is only 2.5 mb. Is it possible that video memory, not system memory, is running low?
I came across this post regarding backgroundColor and mem usage, but I need further explanation. Should I reduce setting the backgroundColor to prevent the UIView's CALayer from hogging too much memory?
Do you have access to the iphone sample code on apple? Sounds like the PageControl Sample Code program is a good example of what you're looking for. And the sample code programs don't have memory leaks or any such problem :) Link here
When you were using instruments, did you check the ObjectAllocations? I've found that to be more useful than the leaks tool (object allocations is one of the tools leaks includes though). I would think that if video memory were running out it would be a different error, but I could be wrong.
Where are you storing all these views? Specifically, do you have some array (NSArray) that has these views when you flip through them?
The views won't get deallocated unless their reference count goes to zero. Your `[[UIView alloc] init] makes the reference count at 1, adding it as a subview makes it 2, and removing it from a subview makes it 1 again. Seeing as you don't get told of a specific leak, it seems that you're not really leaking as much as storing it somewhere.
I've been able to replicate a bug consistently on an iPhone app I'm working on. The bug always follows as soon as my UIViewController's didReceiveMemoryWarning method gets invoked. Some of the issues I'm seeing are as follows:
UITextField's text property niling out.
The previous data in the UITextField is getting appended to a string multiple times, thus giving me corrupted data back when I HTTP to the server
This happens as soon as my breakpoint on didReceiveMemoryWarning hits, otherwise all appears to be working just excellent. My question is, does it sound normal for this odd behavior to occur during a memory leak? If so, what is happening with the UIViewController that's causing such ad-hoc duplication of data in a previous UITextField (which is a part of a UITableViewCell's contentView, so I figure there's some oddity going on with dequeueing of the cell)
It's interesting none the less.
Thanks!
When the iPhone runs low on memory the OS tries to intelligently do things to reduce memory overhead. In a few cases I've seen this cause odd behavior such as text content go missing or a keyboard failing to display.
However you may want to focus on finding the source of your memory problems instead of the results.
Usually, not very much, as long as your application is not using all the memory in the hardware. But memory leaks can stack up, and next thing you know you are out of physical RAM. You may see a sudden performance dip as virtual memory kicks in and parts of your app starting paging to the much slower flash disk storage. This is when your controller will likely get a low memory warning, and UIKit may remove some things it thinks you don't need (like views without superviews, possibly other thigns). Soon after that, the entire app will crash as the iPhone OS forces it to quit because it is using too much memory.
The short version: memory leaks lead to crashes. But the removal of object it thinks you dont need may cause some odd behavior as well.