I read a few memory-leaking issues with UIImagePickerController, so I changed my code to using member variable and was able to take more than a few pictures with the camera. However, I find the photo-taking to take longer and longer time, and eventually it crashed at around 25 photos.
There are two things I do after the photo in the didFinishPickingMediaWithInfo,
1) scale the image down and display that (50x50)
2) save a 320x460 to CoreData
I didn't release any UIImage since it's on the autorelease pool.
What should I do to let the picture-taking go on forever?
Below is the crash log (Type of crash log is listed as Low Memory)
CrashReporter Key: 8e197e26271ae3c2c4d3e725807d023e3c2354cb
OS Version: iPhone OS 3.0 (7A341)
Free pages: 251
Wired pages: 10127
Purgeable pages: 0
Largest process: Journal
Processes
Name UUID Count resident pages
Journal 8960 (jettisoned) (active)
debugserver 130
MobilePhone 529 (jettisoned)
syslog_relay 53
notification_pro 54
DTMobileIS 2285
notification_pro 53
ptpd 276
mediaserverd 252
debugserver 77
debugserver 78
SpringBoard 2470 (active)
notifyd 80
BTServer 123
CommCenter 262
accessoryd 84
configd 70
configd 266
fairplayd 67
mDNSResponder 89
lockdownd 252
syslogd 82
launchd 70
Can you provide backtrace / more crash information?
Is it possible to manage the UIImages yourself, or wrap the call that gives you an autoreleased UIImage with your own NSAutoreleasePool so you can control its lifetime?
Have you tried using Instruments to detect for any possible memory leaks?
This question is pretty old, so hopefully already solved but consider 2 points:
CoreData is a terrible place to save BLOBS, it's really good at text but not so much for binary data.
Your image will live in memory until you give it some place else to go, the only way to get them out of memory is releasing all references to that data.
I would consider caching your images to the file system until they are required again. Basically follow this process:
Capture Image1
Want to take another? Capture Image2 and write Image1 out to disk.
Store the filename for Image1 in CoreData for later retreival.
Repeat as necessary.
It is still possible that you will run out of disk space eventually, but you will have a lot more available disk space than memory, and you can always purge unwanted images from disk or force your user to deal with them in some other convenient manner (upload to the cloud for example).
Related
Our App has Map and GPS based location tracking functionality. This app is already uploaded on Apple Store. The App contains following feature:
Map Shows real-time traffic data Shows real-time traffic event (Accident, Traffic Jam etc.)
User’s GPS location tracking
The application runs fine for the iOS versions 5 and 6.
We are facing following crashing issue for iOS 7 Beta while operating Map functionality in the app. We have used the following features of iOS to render the traffic data and traffic event on Map:
MKAnnotation to render the traffic event
To render the traffic data, app is using the CGBitmapContextCreate function.
context = CGBitmapContextCreate (NULL,
self.mapView.frame.size.width,
self.mapView.frame.size.height,
8,// bits per component
bitmapBytesPerRow,
colorSpace,
kCGImageAlphaPremultipliedLast);
CGContextSetAllowsAntialiasing (context,YES)
Draw the line to display the traffic data on the Bitmap context.
Created bitmap context will be displayed on map using the MKAnnotation API.
App uses the NSOperationQueue to render the traffic and event data because the user interaction with map is smooth. Following is the snippet of the code:
[queue addOperationWithBlock:^{ [Set the required data], [Update the UI] }];
Following are two crash logs which gets generated while random operation n of the Map functionality.
Crash Log - 1
Incident
Identifier: 471EAE21-E118-4E3D-AAAE-D7D82B1D6326
CrashReporter
Key:
bdbf75eb30240449214769478f38830aa7a14f7f
Hardware
Model: iPhone5,2
Process: {Application Name} [246]
Path: /var/mobile/Applications/4FA0A7F2-4998-4F8F-A4C6-66D849D074B8/{Application Name}.app/{Application Name}
Identifier: {Application bunald name}
Version: X.X.X.X
Code
Type: ARM (Native)
Parent
Process: launchd [1]
Date/Time: 2013-08-30 14:21:24.523 +0530
OS
Version: iOS 7.0 (11A4449d)
Report
Version: 104
Exception
Type: EXC_BAD_ACCESS (SIGSEGV)
Exception
Subtype: KERN_INVALID_ADDRESS at 0x8000000c
Triggered
by Thread: 0
Thread
0 Crashed:
0 libobjc.A.dylib 0x38ed3b66
objc_msgSend + 6
1 CoreFoundation 0x2ede773c -[__NSSetM removeObject:] + 92
2 MapKit 0x3002de96 -[MKAnnotationManager
_removeRepresentationForAnnotation:fromCull:] + 490
3 MapKit 0x3004bc54 -[MKAnnotationManager
_removeAnnotation:updateVisible:removeFromContainer:] + 272
4 MapKit 0x3004bb38 -[MKAnnotationManager removeAnnotation:] + 24
5 SLIM 0x00165828 -[TravelStarViewController
mapView:viewForAnnotation:] (TravelStarViewController.m:1735)
6 MapKit 0x3005ea86 -[MKMapView
annotationManager:representationForAnnotation:] + 74
7 MapKit 0x3002a136 -[MKAnnotationManager _addRepresentationForAnnotation:]
+ 362
8 MapKit 0x30028c4a -[MKAnnotationManager updateVisibleAnnotations] +
1034
9 Foundation 0x2f876358 __NSFireTimer + 60
10 CoreFoundation 0x2ee7ae84 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__
+ 12
11 CoreFoundation 0x2ee7aa9e __CFRunLoopDoTimer + 790
12 CoreFoundation 0x2ee78e26 __CFRunLoopRun + 1214
13 CoreFoundation 0x2ede353c CFRunLoopRunSpecific + 520
14 CoreFoundation 0x2ede331e CFRunLoopRunInMode + 102
15 GraphicsServices 0x3387733e
GSEventRunModal + 134
16 UIKit 0x313fc7b0 UIApplicationMain + 1132
17 SLIM 0x000f3fa6
main (main.m:15)
18 SLIM 0x000f3efc start + 36
I think it may be that traffic events are coming in and taking to long in NSOperation. The operation could start, and then be referencing map graphical elements that no longer exist in the MapView. For instance, the user could be scrolling the map, and the NSOperation could "queue" up, and then end when the target region is out of view. The crash is clearly a memory violation. Commonly caused by code trying to access memory that was freed.
I would suggest that you look into your use of NSOperationQueue. I can see how it would make the map interaction smoother, and that part may be OK, but coupled with the "events" could be causing problems.
From the crash I can see that it is running on a CFRunLoop and a NSTimer is firing. NSTimers are notorious for not stopping fully in Objective C. When they finally fire off, the elements they work with are commonly done and freed their memory.
Here is the problem:
A program whose size is 460 bytes will access a series of addresses: 10,11,104,170,73,309,185,245,246,434 and 364.
The page size is 100 bytes and the program only uses 200 bytes in main memory.
If the OS use FIFO algorithm, how many page fault interrupts will occur? Why?
I think may be like this.
address | current Memory | status
10 0-100 page fault
11 0-100
104 0-100|100-200 page fault
170 0-100|100-200
73 0-100|100-200
309 100-200|300-400 page fault
185 100-200|300-400
245 300-400|200-300 page fault
246 300-400|200-300 page fault
434 200-300|400-500 page fault
364 400-500|300-400 page fault
Am I right? I notice this program is 460 byte. And page alignment is 100byte.
I'm trying to decrypt a low memory crash log from my iPhone, and I see that the count number for my application is huge (35314). What does this indicate?
Processes
Name UUID Count resident pages
MobileMail <bd66c3ae9a91225e745044a8051e5458> 906 (jettisoned)
MY_APPLICATION <fe63329c069b3b7fb2796eec33669af6> 35314 (jettisoned) (active)
dataaccessd <cb2dfcefb43430f4550f0187890de64a> 365
apsd <5aa3f4fcfc53b00dde75378aed8e1af3> 216
lsd <f711e4c8e9e3fe740bea8de2b98c3f25> 358
notifyd <f36b987ef3d560324ff7384c1b9e448e> 91
BTServer <399771bd4f5090d5572ab3c753a01c7f> 136
CommCenter <86ed1b990c91d8d3ac6533f2400ab973> 219
SpringBoard <c014cf8d4559f5596a92131934f61166> 6017 (active)
accessoryd <0e514c4b9547bbb5f153435a91b7b831> 114
configd <dcdf074c5152eb97309ea55d200d32ad> 402
fairplayd.K48 <b6aee1a5594de9cadfee552a00f16978> 82
locationd <f496d6de4951e767807ed191addf19ec> 360
mDNSResponder <b14bb33d877732ed866786776833f72c> 178
mediaremoted <ca81c5e8d3b982bca9e1c0f05e203eca> 150
mediaserverd <b09e22f7c7495c8ee56691c74beac1bd> 1343
lockdownd <1bb238048747f8407c2ff1cf0d920c42> 222
syslogd <5532491b0def7a60037a52400c48e715> 102
launchd <bff2d05de78d5832b2c9604413668f3a> 102
**End**
Thank you!
You can see a description of what a resident page is here: http://en.wikipedia.org/wiki/Virtual_memory (specifically under the "Permanently resident pages" title). Basically it is the number of memory pages your process is holding and it really only means that you are using way too much memory (which you already knew ;) ).
My app crashed because of Low Memory. I'm not sure if its entirely my fault because it lists about 7 or 8 other applications that crashed alongside? How should I handle this?
Incident Identifier: 2CC74C33-179F-4CD2-8FAA-00CF0A344749
CrashReporter Key: 1657e021ecba3a19c5ed9f0cff62947a426a2bc2
Hardware Model: iPhone3,1
OS Version: iPhone OS 4.1 (8B117)
Date: 2010-10-24 12:20:38 +0100
Time since snapshot: 2044 ms
Free pages: 1329
Wired pages: 21508
Purgeable pages: 0
Largest process: Instagram
Processes
Name UUID Count resident pages
securityd <3dcc6e23849cb3ee197720700284156d> 309
sandboxd <4c01175d65fe7efb292e307389d3387b> 178
ReportCrash <2ad0d335f1b93cc74e0b5be79850229d> 255
mDNSResponderHel <a0d7f455b6f2069587ea7bc956d79655> 70
Stocks <55e537a6739e58dc068e1436930213ba> 1162
mediaremoted <507d59f44f735d6e2855b23a6275557a> 216
MobileMusicPlaye <02ed082c795446617957bbae8974a2c8> 1052
dataaccessd <40c418e18e9bbd950ef7e3fb593645de> 618
spd <6419715f9e6891201e16b722fca84793> 126
MobileMail <215c71d2434ce352d04786b93cda5340> 2483
calaccessd <90c4c48a02f0dbf0d1adaad27b8d5945> 427
MobileCal <db3e6efa621fc989420ccc43298d5b80> 1619 (jettisoned)
StockTwits <3786112667f535bff10bb6f7966bb852> 2067 (jettisoned)
Mint.com <0f38a50fd98c755ef34e0fe8b0c25adc> 4461 (jettisoned)
AppStore <99bf23a9224aa148ac3e009873f9c7b9> 998 (jettisoned)
Reeder <dcb69039fa5b4426b3db9f9920054f3e> 5835 (jettisoned)
Meebo <22f145af489fb92066006a5a3cac813a> 3684 (jettisoned)
MobileSafari <67a5ebc3754e0ce1e482760c7e56f9c5> 3512
Skype <d570c35d6d2f51713e874937dd8112f4> 4769
Facebook <ae1fa9da7f8951ffbf693bbd0ed36aaf> 2459 (jettisoned)
MobileTimer <98640aaee653fc9188652d6cdab13d67> 1294 (jettisoned)
Twitter <62edb7ce453c603ad1b8b3bdcbc4910b> 5843
MobileSlideShow <40eded841026ed418bebe49a342f2c8f> 3566
Instagram <25e2a98b5d3de6f2cf2f246df8a49a9d> 11523 (active)
misd <d9b8f85780f931007d309fc836185ab0> 119
MobileStorageMou <bd2184fe17b3c9ccbadd9120bd669c99> 102
Preferences <9123dcc666c97bb1d63a5921968c8b34> 1666
MobilePhone <b50b6283b8c52a51fb9e48ee5c909b80> 804
imagent <4ef86a68405738280f19e5fbc0af56db> 291
lsd <4fb2cf7b5475b39b2c56d9588821eb45> 157
SCHelper <30ca097cbb6306cf66157da7fd4de07c> 110
notifyd <ab40010781bef81228df18acf1acdbb2> 129
BTServer <ce7c062b4df09b835c77a6086b7ef0d8> 136
CommCenter <a8a6257faa2a5213f0a2f5c763f9acfe> 335
SpringBoard <983033e585706c1c6c99eed85cd8dbdb> 8315 (active)
accessoryd <b99ccd1b099c015edb93e8d1cbf03e36> 109
apsd <f031a0e787d8840097a4812fb1c89f5e> 240
awd_ice3 <b598d42ac4fdd950ac5c2c9a1835f70e> 124
configd <b2b3af98743381e759dd5b17115a0378> 548
fairplayd.N90 <3ae05b3bbcb034b0d4d4712e8fc19f99> 95
locationd <963c5d93cfaf1b1139045b1658ecfc26> 1031
mDNSResponder <68dc311f118d171ede7b91f43c323b7d> 235
mediaserverd <3ebe3a043c2dba96b70d8ede30bcb6ab> 1220
lockdownd <bfeda752b819f06f4828e112d3ca695c> 326
syslogd <60e8005a73e76d6ee81a8b45a9443a16> 94
launchd <b15ff1a8f2f37c3b0df0343899757b17> 103
**End**
This is expected behavior. Background apps continue to run only at the frontmost app's leisure. If the frontmost app decides it wants your resources, you have no choice but to give them up immediately.
Make sure you fixed all leaks in your app with instruments and with X-code's built-in slangs analyzer.
Run your app as much as time possible with instruments.release all instance variables in dealloc methode and make sure you are reacting to didRecieveMemoryWarning:.
put a breakpoint in didRecieveMemoryWarning: then you can confirm that it is your fault.
I doubt you can. Always check the return value of your allocations, free up memory when you're done, use as little memory as possible, and (I don't remember if this'll work on iPhones) run valgrind to find any memory leaks in your app
I had a similar problem with an app of mine crashing on a low memory warning. I was already freeing up memory in the didReceiveMemoryWarning delegate methods but it was still crashing.
Eventually I commented out the [super didReceiveMemoryWarning] in my RootViewController (I had created my app using the navigation app template). I think the crash was occurring because the RootViewController was being released in that call.
By the time iOS decides to terminate your app it's already too late.
Instead, if you application is active, you need to shed any memory you don't need when you receive the applicationDidReceiveMemoryWarning: message in the UIApplicationDelegate or the equivalent notification.
To minimise the chance of your app being expelled from memory when another app uses too much, all you can do is release any data you can recreate when it goes into the background (pretty much the same process you should be going through when memory is low).
However, you can't ever guarantee that you'll never be terminated.
Heres the problem. I have an app that is essentially an image gallery, it pulls images down from an xml feed, and archives them locally, then gradually loads 5 images at a time into the scroll view to be displayed.
I have had thousands of problems with using [UIImage imageNamed:...] and NSURLRequest/NSData as both cause the app to cache excessive amounts of data. Anyway, I now have the app running at an almost constant 25-30MB, with no sudden spikes, and with only a few kB of data being leaked from memory (due to NSKeyedArchiver and me retaining some values). However the app ALWAYS gets terminated by the OS for (what seems like) no apparent reason.
Sorry if I'm being a bit stupid and not spotting something, the crash report does appear to be telling me that tonnes of memory has been paged by the app, however the allocations and leaks instrument is telling a different story... and really I supposed my question is more along the lines of "why is instruments lying to me?"
Incident Identifier: D258E503-D024-4265-B079-E6C47DE5DA29
CrashReporter Key: c3904eb2c9cf4bf4f89f53fb9c836ad44586684f
OS Version: iPhone OS 3.2.1 (7B405)
Date: 2010-09-21 13:27:50 +0100
Free pages: 464
Wired pages: 12587
Purgeable pages: 0
Largest process: MediaLib
Processes
Name UUID Count resident pages
MediaLib <6db92ce87a5d7e287702f2cb87ba8c53> 30579 (jettisoned) (active)
debugserver <f885fe2348e72988381a73137cc90c7b> 127
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
afcd <ddda2413b8953e5c56721dfe05a82d78> 68
syslog_relay <1c73f841b191556b6911bc6b4736b50f> 63
DTMobileIS <b34df288cd9a07a995933bbd6b66717a> 1169
notification_pro <4c9a7ee0a5bbe160465991228f2d2f2e> 64
ptpd <e3f855cfd629600a4812e7e90c77667e> 191
syslogd <6990426209e51a8ee13c91cd1a050a2e> 78
mediaserverd <2eda3ce5e1c8a1a4d7b8271cef1f2d12> 314
debugserver <f885fe2348e72988381a73137cc90c7b> 74
debugserver <f885fe2348e72988381a73137cc90c7b> 74
debugserver <f885fe2348e72988381a73137cc90c7b> 74
lsd <eb108595d2a932a8d244d1ab7386cd0f> 121
apsd <0775f0d80d1cd1fb4b562d2f94caf051> 172
notifyd <74e4a487a89c31f68917b22605baf6c6> 68
BTServer <21dd98c0ab29b910cd51cb703a9cb9b9> 107
CommCenter <e4b9cc04f083f22232c92ee1363fe669> 170
SpringBoard <745085d9a24a8529f0ceb6c33d766873> 4821 (active)
accessoryd <59ca0ba146c28bf5c8ab6e3d2e81bbad> 97
configd <36001fe17103f8af6d3b525cb23ac8a0> 305
fairplayd.K48 <2d997ffca1a568f9c5400ac32d8f0782> 85
locationd <60fd4d90fec18a76ffc0b8a45351fe54> 600
mDNSResponder <a6f01dd493e3d2bfe318f5d44f8508e2> 107
lockdownd <378f09833cdc57b1b60e42d79c355938> 273
MobileStorageMou <7f2cd9f90fab302a42a63460b1c4d775> 67
launchd <880e75c2db9c0f670516c58935e89b58> 80
**End**
Many thanks in advance for someone who can give me a slap and point me in the right direction ;)
EDIT:
I have just run the app through the activity monitor instrument and this is giving me a "Real Memory" readout of 65-80MB, could this be due to allocation of memory on another thread, which isn't picked up by the allocations instrument?
You should know that NSImage#imageNamed: caches the image. In other words, you lose fine control over the life cycle of those images. Use NSImage#initWith... instead and the cache will not be used.
Also know that a .png image that is a 2KB download can easily be a 6MB image when loaded into an UIImage. Image data is decompressed when loaded into an UIImage so don't look too much to the original size. Look at the size of the bitmap. Usually simply width * height * 4.
You mention that NSURLConnection and NSData are causing memory issues. This is probably because of improper usage. Like failing to do proper memory management.
Post code or more details if you want better hints about resource management.