I am using Xcode's static analyzer to find out the potential leaks in my project and it's working absolutely fine. But, sometimes the analyzer is showing a potential leak even after releasing the object. I am finding it difficult to understand this outcome.
Memory leaks wont cause you any sort of problem except one.
If you have alot of memory leakage and the assigned memory for your app gets full then your app will crash. and except this situation your app will run perfectly fine. X-code's static analyzer is best for checking memory leaks before you run your code.
check this link too
Why should we release?
Related
In a certain (consistent) point when my app is running, I consistently get the xcode error message
Terminated due to memory error.
I cannot find the code causing the error, but I can tell what code is near the error (using breakpoints).
The error is caused directly after returning a certain cell in my implemenation of the
- (UITableViewCell *)tableView:(UITableView *)tableView cellForRowAtIndexPath:(NSIndexPath *)indexPath
UITableViewDataSource delegate method. I can confirm that it is returning a valid UITableViewCell, but I think that explaining and posting that entire method would be a waste of your time. However, I suspect it might be caused by a rapid, massive allocation of memory.
It definitely says Terminated due to memory error, not memory pressure.
I would like to know what is message really means. Also, is there any way to debug this message? No crash report is generated.
I am using ARC and iOS 7.
I was getting this error and could not understand what was wrong.
After some searching I found out that i forgot to disable zombies.
To disable do the following:
I was faced the same issue.("Terminated due to Memory Error")
I had tried the above all answers but nothing work for me. Then i debug my code and found a for loop is running for infinity time with allocating memory to a array with nil value every time.its use 300+MB so it give this error
Thanks.
I had exactly same issue. I thought it caused my program had memory leak or using too much memory. I use instruments and used allocating profile and program works fine. Also I ran program by device long enough, and it also works fine.
I also using iPad 3rd Gen for debugging, it might be causing because of that slow of the device or bug, it it seems like just Xcode and running from Xcode problem. Not the problem of memory leak or allocation.
If you make sure with instruments and running app on device itself and work
I was using Tesseract for OCR and when my target text got scanned, a GIF was supposed to play. When the GIF started to play, there was a memory spike, from 70-80MB to 450MB. The problem was that GIF was taking too much memory, the app would crash and Xcode would show that message. So I removed the concerned imageView from the superview of the ViewController.
imageView.removeFromSuperview
After this, the app would still spike to 450MB but then immediately release and come down to 40MB
Restart device worked for me. “Terminated due to memory error” message stopped to appear.
Edit the scheme, under Diagnostics you'll find several options to guard allocations. Refer to the documentation for details.
Question is: does it really say "terminated due to memory error" and not "pressure"? Check in instruments if your app is running low on memory, if the app does seem to run low on memory then that's what you should focus on regardless what the exact message is.
I got this error because I was adding full size photos to a collectionView cell sized 40x40. Read the 2 comments under the question from #matt. I had to scale down the images before adding them to the cell.
I had similar issue in Xcode 11.3 wherein camera was getting calling every-time we press on try again button. If these is done multiple times then crash happens.
This was fixed when we disabled Zombie objects. Below are steps:
Tap on project name present in top left. This will show list of targets present in project.
Tap on Edit scheme
Select Run option -> Diagnostics -> Uncheck Zombie Objects.
Now, run your project. It should work fine.
With Xcode 11 it started my project in Debug mode. I am doing some image recording/editing/returning to the user and that is not something you can use in Debug. Once I turned to Release mode, all went well.
I've faced this kind of issue due to inattentiveness.
I've been calling a function, which adds imageView as subview in:
override func layoutSubviews() {
super.layoutSubviews()
}
This caused a huge memory usage, so be attentive to this sort of things!
The thing that I noticed is that when I run my app on the device through cable and leave it idle for a long time I will also get that error.
Apple do address this and it just might be that it feels like the app is idle and just kills it.
In my case it was a corrupted Image from the API which raised my memory from 100MB to 4.5 GB due to processing size it took to display on screen!
An infinite loop was the cause of the memory leak for me. I could see the memory in Xcode rising to 1,6 Gb at which point the app crashed. The app's memory usage should be in mb and not gb and it should be relativly stable. If it rises quickly, say 100 mb a second, there's definitely something wrong. If none of the suggestions above have worked, you should 1. check the memory usage of the app, and 2. if the usage is too high, look for loops you've recently added.
I have created an iOS app and need to check the leaks in the app programmatically.
(Hence not using instruments directly)
For the above I use the leaks command as follows:
MallocStackLogging=1 leaks -nocontext
At one point of time this was working properly without issues. But recently I have started getting errors and the leaks commands gives different number of leaks each time.
Has anyone faced a similar issue?
You can programmatically find the current memory stats using vm_statics object. Go through these links to find an implementation of vm_statistics:
1)
http://gamesfromwithin.com/whered-that-memory-go
2)
http://landonf.bikemonkey.org/code/iphone/Determining_Available_Memory.20081203.html
My app crashes (randomly by the way) when running on the device, the crash is not reproduce-able 100% of the time. But it only seems to occur on the device, not in the simulator.
When I run in the simulator with NSZombies I never see problems. Could someone shed some light into my points below.
Device has limited memory, maybe it's crashing because of this.
What would be considered a big memory allocation that would cause a crash?
Would memory leaks/big allocation cause a memory corruption?
All my crashes are always EXC_BAD_ACCESS but like I said, never happens on simulator so I can't run zombies. (or is there another way?)
Note I have also simulated low memory warnings on the simulator to see if that's causing issues.
This is driving me nuts. Any help would be appreciated.
I know where it crashes but I need to know which other classes released this object.
Override -[release] -[autorelease] and -[retain] for your object (or you could do this for NSObject if you didn't know which object), then log them, set breakpoints.
If you identify which object is being released at each point, add timestamps/ object IDs/retaincount to the log statement, then you might be able to throw all of the data into a spreadsheet and then to get the same sort of data that Instruments would give you.
Shame you have to build for 3.0. Almost nobody uses 3.x anymore, and ARC (while not a silver bullet for all issues) is way better than non-ARC.
Also here's a tip: delete the app from your simulator and reinstall it. I had an issue where some of my bundle resources were missing in my project but the Simulator was hanging onto them between builds. If you tried to load a .xib that is no longer in your project, I could see it crashing...
Should the static analyzer provided by Xcode 4.3 catch or flag ivars that are not de-allocated?
I'm relatively new to iOS development and I'm looking for some enligthenment: My team builds our project with static analysis enabled for debug builds in XCode. To evaluate AppCode's inspection feature, I performed an inspection on the entire project.
While I expected AppCode's inspection to be good, I did not expect that it would find 50+ instances of ivars that were not being de-allocated correctly because we have static analysis turned on in Xcode. We verified that AppCode had correctly identified the issue, in a couple cases this resolved known memory leaks.
Should the clang static analyzer have caught these?
I'm hoping its because some project settings haven't been correctly set. As I'd expect the clang static analyzer to at least flag missing de-allocations.
There wouldn't be much market for AppCode if it didn't do something better than Xcode, so I'm sure you'll find at least a few areas where it does something for you that Xcode doesn't. Perhaps this is one of those cases.
On the other hand, the kind of leak that you've described should be pretty easy to spot using Instruments, so it's not like there aren't any tools included with Xcode that could help you find that kind of problem.
Got the answer from the clang mailing list and clang can catch this issue. The problem is that the version of clang that ships with XCode has this feature disabled!
Hello, Seamus. Clang does have support for this check, but it's
disabled by default (possibly because of
http://llvm.org/bugs/show_bug.cgi?id=8838 ).
I agree that Instruments would identify a leak or leaks, and in fact it had. However the process of narrowing down the source of a leak or, more likely, leaks is rarely easy in my experience. The issues AppCode flagged ended up resolving two known leaks the team couldn't narrow down. Additionally it revealed many others that were part of the known issues and others that were unknown.
Once clang is updated it should also nail these kinds of issues.
My app was crashing only when not running using XCode debugger. It was hard to track because I can't debug but I finally figured it out. It was because of calling release on some object not owned by me. Before I corrected it I searched and found 2 related questions here (links below)
iOS App Crashes when running by itself on device, does not crash when running through Xcode using debugger, or in simulator
iPhone crash only when device not connected to xcode, how to understand the crash log?
None of the above question has answered why no crash when running via debugger.So my question is why it happens ? I know reasons for debug/release specific crashes but this is crazy. Is it just by chance although it happened more than 10 times.
What you describe is not atypical of obscure memory-related bugs. You might also want to use debug-malloc at such times. Although that is not guaranteed to find everything. The reason (and it's been happening probably as long as there've been source-level debuggers) is that memory is laid out at least somewhat differently in debuggable code, and when running under the debugger. So the error results in a different piece of memory being (harmlessly) corrupted when under the debugger. When not under the debugger the location corrupted is actually something that your code cares about, and it crashes.
The same could happen in reverse, but you'd never know - if it crashes when run debuggable, you'd find it before switching to running outside the debugging environment.
Reiterating #jyoung's answer since I didn't see it the first time I glanced through:
Try running with Zombie Objects turned off.
In debug mode if you have it turned on it is handling memory allocation differently. Try running it without.
Go to Edit Scheme... > Run > Diagnostics. Then make sure zombie objects is turned off:
Then run through your code path again.
I had this same issue while working on a project modularised with Xcode Frameworks. Even after removing all the logic in AppDelegate and only returning true inside application:didFinishLaunchingWithOptions, I was still getting the crash. Then I switched to my project settings, in the Frameworks, Libraries, and Embedded Content section and changed the embed option for the frameworks I added to Embed & Sign. This was what fixed the issue for me. I hope someone finds this helpful.
I was having this problem as well and was fortunate to figure out the cause quickly, hopefully by posting here I can save someone else some wasted time. To clarify, my app would run with no issues when launched directly from XCode, but would crash immediately when launched manually on the iPad.
The app in question is written in Obj-C but relies on some 3rd party code written in Swift. The Swift code is included in the app as an embedded framework. I had to set "Embedded Content Contains Swift Code" to Yes in the Build Settings for the app (under Build Options), then the problem went away.
I experienced this symptom when I made a NSString, sent a UTF8String from it to another object, and assigned it to a char pointer. Well, it turns out that I forgot to retain the original NSString, which wouldn't have mattered anyway, since I also failed to realize that the UTF8String method (which is presumably an object that gives access to the pointer itself) operates in the autorelease pool. That is, retaining the NSString itself did not fix the problem.
I suppose this appeared to work just fine when attached under the debugger only because I had zombies enabled, so the pointer I had was still valid. I should see if this is the reason it worked; if so, this is a good reason to test with and without NSZombie enabled.
At any rate, this was probably poor design to begin with, and a pretty obvious newbie memory management mistake once I found it. Luckily the console in the Organizer window gave me some hints on where to start looking, and debugging ultimately showed me where my pointer's value was changing. Hope this helps anyone who finds the way here.
I had this issue when accessing SQLite databases from outside the [[NSBundle mainBundle] resourcePath] directory, which caused iCloud errors.
I discovered the error only by installing a Console app onto my iPhone which logged the errors.
Once I accessed the databases from the correct directory, the errors disappeared and the application booted correctly.