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.
Related
I am implementing a simple application for iOS 6.1 and above
I am using iOS SDK 6.1 and ARC enabled in my project.
when I run analyze inside the xCode it doesn't find anything , but when I transferred my app(simulator) to instruments it found a leak of 128 bytes called
Malloc 128 bytes 0x7f95724139d0
the question is: How do I know where it happens inside my application
I did read this https://developer.apple.com/library/mac/documentation/developertools/conceptual/instrumentsuserguide/MemoryManagementforYouriOSApp/MemoryManagementforYouriOSApp.html
But when I click on cycle it is empty :( ,
also StackTrace says :
"No stack trace available for this leak;it maybe allocated before the
Allocation instrument was attached.
However I started the instruments before I run my app .
I guess I am doing something wrong here,
Can someone please help finding the part of code that causing leak?
Run your app on an actual device and then check again.
I have seen "phantom" leaks from the simulator before.
You should always test performance and memory issues on a real device rather than the simulator.
Note that a once-per-lifetime leak of 128 bytes is like a sink faucet that leaks a single drop of water after it's turned off. It's totally insignificant and can be safely ignored. The only time a leak that small is a concern is when it happens over and over. Like every time through a loop. In that case a 128 byte leak would be bad.
I have met the following messages in the console at runtime, and i have no idea why. I have searched everywhere and nobody seems to meet this:
INFO: fetch-response is unable to open the file /Users/userName/Library/Application Support/iPhone Simulator/7.0.3/Applications/964A590B-7131-4BAE-958B-1783BEC193EF/Library/Caches/userName.AppName/fsCachedData/2F1A8708-35A9-491E-9C21-154BA428CA10. Errno: 2
ERROR: failed to mmap cache data from FS: /Users/userName/Library/Application Support/iPhone Simulator/7.0.3/Applications/964A590B-7131-4BAE-958B-1783BEC193EF/Library/Caches/userName.AppName/fsCachedData/83A968D1-0A2B-4D20-97D5-487A876649DC, errno:22
It does not seem to affect the execution though, but I suppose it is not a good sign. I am using Core Data with a timer which frequently updates the database from a server. These messages appear synchronously with the updates, but not systematically. Only one at the time, the "INFO" or the "ERROR". Reset Content and Settings in the Simulator did not solve the problem.
Does anyone have any idea about the meaning of these messages?
I experienced this when running on my device with an app I am building. It has worked perfect for weeks and then all of a sudden this error. I figured out that it is due to a lack of memory available on the device. I use a little app call "System Status" that allows you to view the memory stats and release any old unused memory. I only get this error in Xcode when I have less than 5% available memory on my device. Therefore it cannot load the cache file the app is request, hence the error. Either close all your multitasking apps and restart your device or get the app and free you memory.
After some testing/debugging (sorry for the delay), I have at least a temporary solution.
Because of the multi-threaded saving process of Core Data, I found it a little tricky to identify the exact error location, but it definitely appears that the error occurs when Core Data is trying to save one of the context in the stack (probably the last "root" one).
As each save take a few seconds (without freezing the UI :p) , I figured the error could be generated by a "save overlap".
So even if I do not have enough to be sure, reducing the save frequency effectively solved my problem: no message anymore in the output.
Now there still is a hitch, and any expert answer would be much appreciated!
Uninstalling the app from the device and installing it again removes this error message.
Note that that doesn't fix the problem if you can see this log from earlier versions of your app that is already on your users' devices. It's generally okay to uninstall-install, though, if you're only seeing this during the development phase.
For me this happened when my phone ran out of batteries and died as a result. Deleting the app, then restarting my phone, then rebuilding/installing solved the problem.
I ran into this error because my app was stuck in an infinite loop, doing network requests multiple times a second, causing the file to be overwritten before it could be read.
In the situation described in the original post, this might very well be the case.
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...
I have a pretty strange problem: after some time the images used in my UIs stops displaying on my iPad(not all, just the 80%).
I've checked it with instruments there is no memory leak and the app's total allocations is 5MB so memory should not be an issue.
I'm using xibs named like SomeViewController~ipad.
When I checked I/O Activity with instruments I noticed that after some time the app stops looking for background.png but looks for background~ipad.png and gives back "No such file or directory" error.
Is there something I can do to prevent this?
In the end I've found out that it was some kind of bug in a iOS 5.0.x version. After upgrading to 5.1.1 the bug disappeared.
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.