I am writing an IOS app. It involves a lot of data downloading which involves images and text in JSON format. I am using NSOperation Queue to make the download process sequential. The entire app works fine in iPhone4 and iPhone4s but in iPhone 5 the app crashes while inserting data in to the database. I have an API call which returns about 350 items back. WHile inserting these records to database the app crashes.
I am not getting any crash logs while debugging. The app simply quits. But from device logs within the Organizer it shows Memory warning. MyApp is the name of my application.
Dec 3 17:14:21 Gavs-iPhone MyApp[6673] <Warning>: Inserted Reward
Dec 3 17:14:21 Gavs-iPhone MobileMail[6648] <Warning>: Received memory warning.
Dec 3 17:14:22 Gavs-iPhone MyApp[6673] <Warning>: Inserted Reward
Dec 3 17:14:22 Gavs-iPhone UserEventAgent[14] <Notice>: jetsam: kernel termination snapshot being created
Within device Console I can see this
Processes
Name <UUID> rpages recent_max fds [reason] (state)
keybagd <03955fb37478382481fc34df706700a1> 233 233 100 [vm-pageshortage] (daemon) (idle)
wirelessproxd <b5a0169c073b3fa7a2e63079774626bc> 97 97 100 [vm-pageshortage] (daemon) (idle)
MobileMail <759a544834f73ebfb26a73e4c16a71d6> 987 987 100 [vm-pageshortage] (resume) (continuous)
tccd <96df95e7143c3cdba0e4ce226d849f14> 148 148 100 [vm-pageshortage] (daemon)
MyApp <aa954e20bdf13ecf9fa250862caf480e> 6296 7314 100 [vm-pageshortage] (frontmost) (resume)
What confuses me is this happens only on iPhone5. All devices runs on IOS 7.0.4 .
Is iPhone 5 allocating lesser memory compared to previous models? To add NSZoombies is not enabled.
Whats going wrong here?
Thanks
Related
I have a location service based tracking and geofencing app which would run for days and weeks in the background on and iOS 12.2 ff device.
Now with iOS 13.2 the app gets terminated after a variable amount of time, but at least several hours, due to excessive cpu usage:
Date/Time: 2019-11-09 23:25:18 +0200
End time: 2019-11-09 23:26:06 +0200
OS Version: iPhone OS 13.2 (Build 17B84)
Architecture: arm64
Report Version: 29
Incident Identifier: 5B46660C-A347-477F-8AE2-B1401080892B
Data Source: Microstackshots
Shared Cache: 0x44db8000 94FD24C8-F407-3A82-8D27-367F5B6C7BEC
Command: Anchorwatch
Path: /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
Identifier: de.sioned.Anchorwatch
Version: 2.2.1 (14)
Beta Identifier: 68A95EFC-B341-476C-9277-D711242471EC
PID: 57424
Event: cpu usage
Action taken: Process killed
CPU: 48 seconds cpu time over 48 seconds (99% cpu average), exceeding limit of 80% cpu over 60 seconds
CPU limit: 48s
Limit duration: 60s
CPU used: 48s
CPU duration: 48s
Duration: 48.39s
Duration Sampled: 14.08s
Steps: 16
Hardware model: iPad6,12
Active cpus: 2
Heaviest stack for the target process:
16 ??? (libsystem_pthread.dylib + 49032) [0x1c4f64f88]
16 ??? (libdispatch.dylib + 74516) [0x1c4ecb314]
16 ??? (libdispatch.dylib + 36344) [0x1c4ec1df8]
16 ??? (libdispatch.dylib + 33488) [0x1c4ec12d0]
16 ??? (libdispatch.dylib + 104312) [0x1c4ed2778]
16 ??? (libdispatch.dylib + 33948) [0x1c4ec149c]
16 ??? (libdispatch.dylib + 124996) [0x1c4ed7844]
16 ??? (libdispatch.dylib + 125216) [0x1c4ed7920]
16 ??? (libsystem_kernel.dylib + 158196) [0x1c50419f4]
Powerstats for: Anchorwatch [57424]
Bundle ID: de.sioned.Anchorwatch
Adam ID: 0
Is first party: No
App version: 2.2.1
Build version: 14
Is Beta: No
Share with Devs: No
UUID: 1C943425-70F9-3670-98D0-45D3051B4BB7
Path: /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
Architecture: arm64
Footprint: 1046.66 MB
Start time: 2019-11-09 23:25:52 +0200
End time: 2019-11-09 23:26:06 +0200
Num samples: 16 (100%)
CPU Time: 13.971s
Primary state: 15 samples Non-Frontmost App, Non-Suppressed, Kernel mode, Effective Thread QoS Background, Requested Thread QoS Default, Override Thread QoS Unspecified
User Activity: 0 samples Idle, 0 samples Active, 16 samples Unknown
Power Source: 0 samples on Battery, 0 samples on AC, 16 samples Unknown
16 _pthread_wqthread + 275 (libsystem_pthread.dylib + 49032) [0x1c4f64f88]
16 _dispatch_workloop_worker_thread + 587 (libdispatch.dylib + 74516) [0x1c4ecb314]
16 _dispatch_lane_invoke$VARIANT$mp + 419 (libdispatch.dylib + 36344) [0x1c4ec1df8]
16 _dispatch_lane_serial_drain$VARIANT$mp + 299 (libdispatch.dylib + 33488) [0x1c4ec12d0]
16 _dispatch_mach_invoke$VARIANT$mp + 471 (libdispatch.dylib + 104312) [0x1c4ed2778]
16 _dispatch_lane_serial_drain$VARIANT$mp + 759 (libdispatch.dylib + 33948) [0x1c4ec149c]
16 _dispatch_event_loop_drain$VARIANT$mp + 315 (libdispatch.dylib + 124996) [0x1c4ed7844]
16 _dispatch_kq_drain + 123 (libdispatch.dylib + 125216) [0x1c4ed7920]
16 kevent_id + 8 (libsystem_kernel.dylib + 158196) [0x1c50419f4]
1 <User mode>
Binary Images:
0x102d80000 - ??? Anchorwatch <1C943425-70F9-3670-98D0-45D3051B4BB7> /private/var/containers/Bundle/Application/32CD03B2-449C-4E84-8E06-79FA9B50F3A9/Anchorwatch.app/Anchorwatch
0x1c4eb9000 - 0x1c4f2dfff libdispatch.dylib <B7EED4C7-560D-3DA6-9B50-ED52A150AAC6> /usr/lib/system/libdispatch.dylib
0x1c4f59000 - 0x1c4f69fff libsystem_pthread.dylib <F8B082D8-24D9-3B1E-B80B-645FC8A88E14> /usr/lib/system/libsystem_pthread.dylib
0x1c501b000 - 0x1c5048fff libsystem_kernel.dylib <AE4C3D7A-7D08-33E7-BCC6-11AC821B4E48> /usr/lib/system/libsystem_kernel.dylib
While in background the app does nothing more than to write each location update to a sqlite database and checking the current location against a safety perimeter.
There is no reason to assume that the app suddenly after several hours would require such a high cpu usage.
I have not the slightest idea how to approach the problem and I am not even sure if I can do anything about it or if it is a bug in 13.2 and I have to wait for a fix.
My first assumption was, that the old iOS 12.0 bug which terminated background apps without reason and which was fixed in 12.2 was back. But that here seems to be something new. I was able to run the test app iOS 12 terminates apps in the background for no reason for several days.
Any hint how to interprete the log and take action ?
Edit:
It seems, that this is related to iOS 13.2 message: nehelper sent invalid result code [1] for Wi-Fi information request
Location service queries the WiFi interface in second intervals. Instrument shows that these query calls have a memory leak.
Turning off WiFi on the device seems to solve the problem, though that is no true solution. Now waiting for iOS 13.3 to leave beta.
It turned out, that a third party framework that I am using launches calls to CNCopyNetworkInfo in second intervals. These calls could not fullfilled as my App had no WiFi capabilities enabled and thus the calls to CNCopyNetworkInfo caused small memory leaks that added up over time.
After enabling WiFi access capabilities the memory leaks vanished.
I have an app which is crashing with
Terminating in response to backboardd's termination
Here the app crashes and even the Springboard. You can see the Apple logo for a short time and it seems that the device is rebooting.
This is taken from the device log
Incident Identifier: AECC8A4C-B6E0-47B5-A2DD-C3A367107087
CrashReporter Key: 26d2ecafff1bd02c1e774f056b3d20c8b03241c3
Hardware Model: iPad4,2
OS Version: iPhone OS 7.1.2 (11D257)
Kernel Version: Darwin Kernel Version 14.0.0: Thu May 15 23:17:54 PDT 2014; root:xnu-2423.10.71~1/RELEASE_ARM64_S5L8960X
Date: 2015-08-17 16:49:06 +0200
Time since snapshot: 117 ms
Free pages: 114466
Active pages: 5397
Inactive pages: 67177
Speculative pages: 258
Throttled pages: 0
Purgeable pages: 0
Wired pages: 52014
File-backed pages: 43687
Anonymous pages: 29145
Compressions: 4016283
Decompressions: 516269
Compressor Size: 10655
Uncompressed Pages in Compressor: 30459
Largest process: backboardd
Processes
Name <UUID> rpages recent_max fds [reason] (state)
CloudKeychainPro <0b4f59ba89df38039892ce8ad342a013> 152 152 100 (daemon) (idle)
syslog_relay <1dc57ae8a60c3654bbf327c16a01d551> 88 88 100 (daemon) (idle)
storebookkeeperd <83b2723af35f32b3beafb32abd677b7b> 509 509 100 (daemon) (idle)
adid <707928b1d97336d5beb5291562421efd> 130 130 200 (daemon) (idle)
aosnotifyd <6e3b66f6dad73af08e7f49db92efc045> 559 559 100 (daemon) (idle)
installd <4e0b7c36602737a3b0dd0bd733eb4378> 195 195 100 (daemon) (idle)
mobileassetd <8574a112afc337638edcd9ac0404f1c6> 1531 1531 200 (daemon) (idle)
gamed <943623c4259f306e93b97ce614edf89e> 785 785 100 (daemon) (idle)
afcd <208713527dc0315a9198e99db64d3cf1> 119 119 100 (daemon) (idle)
timed <294a840542e13dca88162e0fbe687f94> 244 244 100 (daemon) (idle)
keybagd <92fe9694044a3f4387459afb0f88a705> 114 114 100 (daemon) (idle)
MobileGestaltHel <f20bac36fcac32628ad30c2da33effd8> 161 161 100 (daemon) (idle)
geod <fb5d1b37f6703663818bd883ed500ea6> 263 263 100 (daemon) (idle)
softwareupdatese <5cfe93434a573beeb6ef41304af4a352> 949 949 200 (daemon) (idle)
assetsd <fd2bd931098b341f846302c614cc5ae8> 471 471 200 (daemon) (idle)
IMDPersistenceAg <9bd313f498a13e61b54d2ae6ec19ea2c> 220 220 100 (daemon) (idle)
accountsd <ee22a71a12f933179729608a16b45094> 622 622 100 (daemon) (idle)
itunesstored <3768d425f2103c209fdd1722b8f5acaa> 1171 1171 100 (daemon) (idle)
securityd <d79d9800981f3cedad0ca6975c9b9f0c> 602 602 100 (daemon) (idle)
mediaremoted <336797e58ac036298bdcdd5d558c227c> 245 245 100 (daemon) (idle)
coresymbolicatio <0b798227409d39c3b23e63bf4bcb820d> 89 89 100 (daemon) (idle)
DuetLST <06955a348ea2371e8d7ec43936431caa> 452 452 100 (daemon) (idle)
sandboxd <e75c30438fb73c20a67dd096f80352e3> 130 130 100 (daemon) (idle)
networkd_privile <5bd47a1c3d12302ea6d78a52cf4ab0a4> 90 90 100 (daemon) (idle)
routined <6dbb51d76fbb3d79aa6ea9f3c16c608f> 383 383 100 (daemon) (idle)
lsd <f2a08944163c31b9a8fd7f3a43ceacb0> 261 261 100 (daemon) (idle)
assistantd <5b53d51bff1236baa617758c37d4f862> 418 418 100 (daemon) (idle)
xpcd <8b704605eb243a10bfe026138c1908cd> 292 292 100 (daemon) (idle)
librariand <c8d851b111f0324e8de6eaf46ac108d0> 380 380 100 (daemon) (idle)
MobileMail <f359afe7da513629b0a6b8aa32a0b90b> 1073 1073 100 (resume) (continuous)
tccd <e37a9bd3403c34adbbd9d75e9022240a> 179 179 100 (daemon)
kbd <2669fa0ab11a356fbd9482881637e730> 595 595 100 (daemon)
MyCrashingApp <25870f37b79d36e584a2e7c6db2717f5> 176783 176783 100 [per-process-limit] (frontmost) (resume)
ptpd <606d697050af3b23a54e4d75eafef6c0> 605 605 200 (daemon)
identityservices <1695cbd72da83c4c87c568bd53a01d24> 442 442 200 (daemon)
wifid <c0ed3dbc8d7f329489a04faf460c027c> 411 411 200 (daemon)
syslogd <88667a0c3dc6398e9b1c6a0c5a5d8f24> 187 187 200 (daemon)
powerd <1a8551a962783aa9899be0e55a9c1e58> 152 152 200 (daemon)
locationd <3480b01585f039ca9c45ecc16928d8b0> 1139 1139 200 (daemon)
imagent <5a1a726d45e033f2bea34c3ae04e817c> 300 300 200 (daemon)
dataaccessd <ae41b26410e3338ba33e337fb5439069> 1131 1131 100 (daemon)
apsd <f96e01aab90637b0822aff105bf78d70> 578 578 200 (daemon)
mediaserverd <6c2cee9548813cea95bf5548d3411408> 1087 1087 100 (daemon)
iaptransportd <009cdd0e53bf34829b6a8b69e0ca49bf> 260 260 200 (daemon)
mDNSResponder <090a345fd6e13f52b156a3eb9a0e78ee> 220 220 100 (daemon)
sharingd <63eae5785eac326987c89d771258ebf8> 571 571 200 (daemon)
SpringBoard <ccb584e84f2f3005a9c20897fdb783dd> 6419 6419 100
backboardd <3085386f5f99357aa9f055e0fb79b827> 181876 181876 100 [per-process-limit] (daemon)
fseventsd <8b8df4c7b46b3dcfb4e1b1d8a6cbb686> 1203 1203 50 (daemon)
lockdownd <6bdd33b3920236808292915812d386c8> 344 344 50 (daemon)
wirelessproxd <41e0cf822ff33124b3c3949cedce7fd2> 196 196 50 (daemon)
configd <2123dc8c1e103375aec0905809a8d38e> 646 646 50 (daemon)
aggregated <178824f7adc231249e9e341c03c36855> 590 590 100 (daemon)
fairplayd.A2 <9948545906083ff9962c310943eb34de> 148 148 100 (daemon)
BTServer <5540f7e4ecd535b9a48b50258130dbd1> 404 404 100 (daemon)
distnoted <a237d6a85cae3c409b914ccb8e5b63f1> 182 182 100 (daemon)
UserEventAgent <f9cb9c166628392a9d190acff16950b9> 995 995 100 (daemon)
filecoordination <4d26113e2e3d3b21832eb866679edf38> 251 251 200 (daemon)
itunescloudd <266cb30204a039d5b2f5aba30cf05015> 1044 1044 100 (daemon)
DTPower <79ced86c61333b6aaa2460276eb0b8eb> 282 282 200 (daemon)
ubd <b54681e3319e36b48148ab2026ebf542> 655 655 200 (daemon)
eapolclient <a5ac733ff23936b4ab05dde3fd5fb17b> 173 173 50 (daemon)
afcd <208713527dc0315a9198e99db64d3cf1> 134 134 200 (daemon)
notification_pro <293150329f1d317c99a6c5fa2e25963a> 140 140 200 (daemon)
DTMobileIS <100bfdacf0a63ae9ab08b27669042812> 2292 2292 200 (daemon)
LeakAgent <30856ea2089a3263aaf27fd9faee406d> 3520 3520 100 (daemon)
networkd <7262086478d63812ae40c561e8e1acbf> 509 509 200 (daemon)
WirelessCoexMana <1e096a90f671399d975e83beb668eb91> 151 151 100 (daemon)
touchsetupd <9d37501e59f13ca1b1577435bdb43a9f> 197 197 200 (daemon)
CommCenter <e5c6b5b1f64833de93bd22bbe135c9b6> 1196 1196 100 (daemon)
notifyd <1d555aa3d08c336294a38d9c134dca00> 319 319 100 (daemon)
**End**
I can't see any hint where the problem lies. The app crashes when I push a new view controller on the navigation stack. On this view controller there is a full screen label. The error also happens after opening and closing the view controller 40 times or so.
Similar questions have different hints:
Too much memory from OS requested
Too many animations/didn't queue animations
Use instruments
Memory warning
So the memory management problem is the most likely one. I tried to use Instruments, but Leaks didn't give me some useful hints (only some malloc and auto release pool with 48 kB max. - seems a OS bug). Also Zombies and Activity Monitor aren't helpful. Using Instruments makes everything really slow.
Only with allocations I saw the UILabel subclass is taking too much space. Every time the new view controller is created, the memory increases by 10 MB (persistent bytes) and that is only the label!
Too make things more complex I'm using Xamarin.iOS. The garbage collector isn't deallocating the view controller when it popped off the navigation controller. But it does it at some time. I think when the system needs more space (nothing left) than the GC kicks in. I could reproduce this behavior in a simple project with my big sized label.
Why does the garbage collector doesn't kick in? I get memory warnings but I can't release something. Normally the view controller and its subviews should get deallocated when they are unloaded from the navigation controller.
When I know why my app is crashing I can do something against this. How can I debug this issue?
Edit:
Now I tried to crash the app on an iPhone. Here you can find the debugger output and here the device log. Again it seems that I'm running out of memory. But my only hint is still the label, because none of the tools can tell me exactly where the problem lies.
I made the following steps to reduce the memory pressure:
used separate class for my custom EventArgs (before: in view controller)
no anonymous function for button in UINavigationBar
no anonymous funciton for UIActionSheet
rewrote EventHandler in that way that I subscribe to them in viewWillAppear and unsubscribe in viewWillDisappear (most of the time)
added Target for UIGestureRecognizer in viewWillAppear and removed it in viewWillDisappear
removed cycle between view controller and datasource through using a WeakReference
I made some checks and it now seems to work. For testing if a view controller is deallocated or not use this:
protected override void Dispose (bool disposing)
{
Console.WriteLine (String.Format ("{0} controller disposed - {1}",
this.GetType (), this.GetHashCode ()));
base.Dispose (disposing);
}
Through this and commenting the things out I were able to detect the reference cycles. I hope I fixed all problems. The main problems were the EventHandler.
For solving my issue the following questions belong to it:
Clicked handler not executed for UIButton in UIBarButtonItem
How to break reference cycle between view controller and data source
Through presenting new view controller viewWillDisappear on parent is triggered where I unsubscribe from the events
RemoveTarget from UITapGestureRecognizer
Add/remove EventHandler for UIBarButtonItem
The following links were helpful in resolving the memory issue:
Memory and Performance Best Practices
Is this a bug in MonoTouch GC?
Memory Management Pitfalls in Xamarin iOS - Introduction + Part 1 + Part 2
Weak Event Pattern in MonoTouch
iOS Memory Managment by Rodrigo Kumpera (Xamarin)
My App Crashed, Now What? – Part 1 + Part 2
signal
I've been somewhat concerned at the number of R14 errors I'm getting on Heroku recently.
I don't know if this has anything to do with using Unicorn. Or having recently installed New Relic or Logentries. I really can't work it out.
I have "installed" Oink and have just received the following analysis but have no read idea how to fully understand what it's trying to tell me.
---- MEMORY THRESHOLD ----
THRESHOLD: 0 MB
-- SUMMARY --
Worst Requests:
1. Nov 13 02:53:51, 70836 KB, messages#getmessagecount
2. Nov 13 02:03:04, 65836 KB, messages#getmessagecount
3. Nov 13 02:21:46, 60236 KB, messages#getmessagecount
4. Nov 13 01:32:47, 6328 KB, messages#deletemessage
5. Nov 13 01:33:43, 6328 KB, locations#sendprofiles
6. Nov 13 01:32:56, 6328 KB, messages#deletemessage
7. Nov 13 01:32:58, 6328 KB, messages#deletemessage
8. Nov 13 01:32:49, 6328 KB, messages#deletemessage
9. Nov 13 01:47:46, 5300 KB, messages#getmessagecount
10. Nov 13 03:09:56, 5300 KB, messages#getmessagecount
Worst Actions:
9, messages#deletemessage
7, messages#getmessagecount
1, locations#sendprofiles
1, photos#photodatarequest
1, messages#getmessages
Aggregated Totals:
Action Max Mean Min Total Number of requests
messages#getmessagecount 70836 29814 464 208700 7
messages#deletemessage 6328 3016 180 27144 9
locations#sendprofiles 6328 6328 6328 6328 1
photos#photodatarequest 460 460 460 460 1
messages#getmessages 300 300 300 300 1
I'm concerned, as a layman, that my message#getmessagecount is eating a LOT of memory. Is that what the above means?
If so ... the routine is simply:
def getmessagecount
#messagecount = Message.where(recipient: current_user, messageSysMessCode: 0, messageAdminMessage: false).count
end
And I have no idea how this could be "leaking" memory.
The graph of memory usage on Heroku over the last day looks like:
I'm using Ruby 2.1.4 and Rails 4.1.7 if that's any help. I'm using two Web dynos and one Worker.
Oh ... and my delete message routine is:
def deletemessage
#message = Message.where(recipient_id: current_user.id, id: params[:messageID]).first
if (#message)
#message.delete
#code = "OK"
else
#code = "Couldn't delete message"
end
end
This is killing my performance (if that's the right thing to say) every 3 hours or so. I have no idea why this is ramping up every 10 minutes (which I hopefully infer from reading the graph). 10 minutes might be significant as I have an iPhone app which is polling the getmessagecount routine every 10 mins with a single test app. I can only wonder what will happen if 10 copies of the app (or 1,000's) start hitting the server?
Any help would be very deeply appreciated.
I am facing a strange issue in MobileVLCKit for iOS.I am playing RTSP links in my app. I have set the flag to play audio and video in background to true in my app. So when the app goes in background the video playing in my VLC player keeps playing without any problem.
But on iPhone 4 (with iOS 7.0.4) when I lock the screen of my iPhone when the video is playing, the app crashes without showing any logs. Strange thing is that if I send the app in background by pressing home button then the app doesn't crash. The issue is only on iPhone 4 and not on iPhone 5.
Have somebody come across such issue before?
Bellow is device crash log:
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: 019323.846533 wlan.A[400] AppleBCMWLANNetManager::updateLinkQualityMetrics(): Report LQM to User Land 100, fAverageRSSI -69
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: ALS: AppleARMBacklight::setBacklightEnableGated 0 (set level to 0x1c8)
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: AppleMultitouchN1SPI: updating power statistics
May 27 03:18:41 My-iPhone-VI kernel[0] <Debug>: ALS: AppleARMBacklight::handleMessageGated - framebufferState -> 0
May 27 03:18:41 My-iPhone-VI backboardd[28] <Notice>: Posting 'com.apple.iokit.hid.displayStatus' notifyState=0
May 27 03:18:41 My-iPhone-VI SpringBoard[34] <Warning>: [MPUNowPlayingController] Not registered for now playing notifications. Ignoring call to -unregisterForNotifications.
May 27 03:18:41 My-iPhone-VI backboardd[28] <Notice>: MultitouchHID: detection mode: 0->255
May 27 03:18:41 My-iPhone-VI MyApp[817] <Warning>: log: applicationWillResignActive
May 27 03:18:41 My-iPhone-VI MyApp[817] <Warning>: log: applicationDidEnterBackground
May 27 03:18:42 My-iPhone-VI profiled[818] <Notice>: (Note ) profiled: Service starting...
May 27 03:18:42 My-iPhone-VI ReportCrash[819] <Notice>: ReportCrash acting against PID 817
May 27 03:18:43 My-iPhone-VI ReportCrash[819] <Notice>: Formulating crash report for process MyApp[817]
May 27 03:18:43 My-iPhone-VI com.apple.launchd[1] (UIKitApplication:com.My.MyApp[0x19d8][817]) <Warning>: (UIKitApplication:com.My.MyApp[0x19d8]) Job appears to have crashed: Segmentation fault: 11
May 27 03:18:43 My-iPhone-VI backboardd[28] <Warning>: Application 'UIKitApplication:com.My.MyApp[0x19d8]' exited abnormally with signal 11: Segmentation fault: 11
May 27 03:18:43 My-iPhone-VI mediaserverd[46] <Warning>: Encountered an XPC error while communicating with backboardd: <error: 0x3cd9f744> { count = 1, contents =
"XPCErrorDescription" => <string: 0x3cd9f9dc> { length = 22, contents = "Connection interrupted" }
}
May 27 03:18:43 My-iPhone-VI ReportCrash[819] <Notice>: Saved crashreport to /var/mobile/Library/Logs/CrashReporter/MyApp_2014-05-27-031842_My-iPhone-VI.plist using uid: 0 gid: 0, synthetic_euid: 501 egid: 0
May 27 03:18:53 My-iPhone-VI profiled[818] <Notice>: (Note ) profiled: Service stopping.
Below is the stack trace taken in method didEnterBackground:
Stack trace : (
0 MyApp 0x0010a191 -[MyAppAppDelegate applicationDidEnterBackground:] + 76
1 UIKit 0x2fc85543 <redacted> + 590
2 UIKit 0x2fc06ae1 <redacted> + 764
3 UIKit 0x2fc06721 <redacted> + 72
4 UIKit 0x2fc6bb3d <redacted> + 664
5 GraphicsServices 0x320a270d <redacted> + 608
6 GraphicsServices 0x320a22f7 <redacted> + 34
7 CoreFoundation 0x2d4599df <redacted> + 34
8 CoreFoundation 0x2d45997b <redacted> + 346
9 CoreFoundation 0x2d45814f <redacted> + 1398
10 CoreFoundation 0x2d3c2c27 CFRunLoopRunSpecific + 522
11 CoreFoundation 0x2d3c2a0b CFRunLoopRunInMode + 106
12 GraphicsServices 0x320a1283 GSEventRunModal + 138
13 UIKit 0x2fc66049 UIApplicationMain + 1136
14 MyApp 0x001078e9 main + 116
15 libdyld.dylib 0x37d26ab7 <redacted> + 2
)
You need to disable video decoding prior to entering the background state. Otherwise, MobileVLCKit will try to draw OpenGL contents in the background which will be prevented by the OS by terminating the app.
You can disable video decoding by setting the current video track on your media player instance to -1. Once your app is moved to the foreground again, switch it back to the currently decoded video track (so you should cache it if your stream includes more than one video track).
When disabling video decoding, audio decoding is not affected and will continue just fine. This approach also got the benefit of saving CPU load and battery.. ;)
This is how VLC for iOS works, too. :)
i think You need to disable video decoding prior to entering the background state,this will work for sure this is major thing Apple says that a fix for the home screen crashes is coming also you can read here more How to take a screenshot on iphone without using lock button
I'm experiencing a crash on my iPad which I think is related to my app just running out of memory, however I can't seem to glean any information about the crash itself in order to resolve it. The app uses ARC.
The app spends about 20 minutes downloading data from our server and populating a Core Data model. Around the 20 minutes mark, the app crashes.
The device isn't running out of space - in fact the downloaded content takes up just a hundred megabytes. I'm using only a single managed context object (nb. I'm not saving the context until the entire data set has downloaded).
When I run in debug with an exception breakpoint enabled, I app just crashes without breaking and without displaying any type of warning or error.
Any advice on how to track down the problem? From the crash log below, does it look like the app is just running out of memory, or might it be
Here's the crash log:
Incident Identifier: A619465F-2E85-4BBC-BBE7-2330D4700FB8
CrashReporter Key: 6fa0c5a4f6cbeaf7a98e6c0e9ad8be6b27789039
Hardware Model: iPad2,2
OS Version: iPhone OS 6.0.1 (10A523)
Kernel Version: Darwin Kernel Version 13.0.0: Wed Oct 10 23:29:31 PDT 2012; root:xnu-2107.2.34~2/RELEASE_ARM_S5L8940X
Date: 2013-04-27 09:53:43 +0200
Time since snapshot: 152 ms
Free pages: 934
Active pages: 3455
Inactive pages: 1821
Throttled pages: 103117
Purgeable pages: 0
Wired pages: 18795
Largest process: GreaseBook
Processes
Name <UUID> rpages recent_max [reason] (state)
MobileMail <27df582d2bed3501834661269810ad98> 3928 3928 [vm] (continuous)
kbd <24d58ac14ed3340380492fef46eac29d> 574 574 [vm] (daemon)
tccd <eb5ddcf533663f8d987d67cae6a4c4ea> 281 281 [vm] (daemon)
GreaseBook <2f5df68a7078386298eadbb24ebbdb33> 84210 84210 [vm] (frontmost) (resume)
ptpd <0cac6936ffeb362d98eb8073af935d21> 992 992 (daemon)
mediaserverd <bdc35c073fe134b9a39b96342a80159e> 1082 1082 (daemon)
syslogd <cbef142fa0a839f0885afb693fb169c3> 281 281 (daemon)
locationd <4bee615548dd33f48e18bfed4296f05d> 1675 1675 (daemon)
wifid <a243b2fcde2537159660b3ee7e809df4> 649 649 (daemon)
aosnotifyd <01901b13681f3582b5bfbe53504d08d6> 480 480 (daemon)
dataaccessd <117e4e475b14305982f52484564cfbc7> 1319 1319 (daemon)
iaptransportd <f784f30dc09d32078d87b450e8113ef6> 241 241 (daemon)
SpringBoard <0e3571e8067533e2811a6d444f10a349> 4058 4058
backboardd <a9b5346126a939dfb0920a4bbc48201b> 6057 6057 (daemon)
imagent <d15f873abdd233f0a34d77a7d36e9e0f> 329 329 (daemon)
mDNSResponder <3e557693f3073697a58da6d27a827d97> 283 283 (daemon)
UserEventAgent <6edfd8d8dba23187b05772dcdfc94f90> 589 589 (daemon)
syslog_relay <45e9844605d737a08368b5215bb54426> 0 0 (daemon)
CVMServer <3ec015e0150d341a929ebbbc45f4c8ac> 104 104 (daemon)
afcd <b0aff2e7952e34a9882fec81a8dcdbb2> 165 165 (daemon)
notification_pro <845b7beebc8538ca9ceef731031983b7> 203 203 (daemon)
filecoordination <fbab576f37a63b56a1039153fc1aa7d8> 195 195 (daemon)
distnoted <a89af76ec8633ac2bbe99bc2b7964bb0> 132 132 (daemon)
apsd <d0e432fd45023d629ffb305b7e79d7fb> 403 403 (daemon)
aggregated <cd70154f955c31bbab58bf5f0acd3acd> 108 108 (daemon)
networkd <b24547cbe04b3e94a4bd406e586cdf8a> 222 222 (daemon)
BTServer <f57113a7cc2c33678ee832bc088276be> 356 356 (daemon)
configd <4245d73a9e96360399452cf6b8671844> 576 576 (daemon)
fairplayd.K94 <1a5f575df8f4368db1eae7ba3da11150> 270 270 (daemon)
fseventsd <996cc4ca03793184aea8d781b55bce08> 362 362 (daemon)
powerd <2d2ffed5e69638aeba1b92ef124ed861> 198 198 (daemon)
securityd <c35e701a5aab3968ae8d93ef8db02e07> 159 159 (daemon)
lockdownd <481275a4062931708a7440ff0f73f229> 495 495 (daemon)
CommCenterClassi <c10fa2a1b7673e1ab14e6ecd11b9b7e7> 557 557 (daemon)
notifyd <51c0e03da8a93ac8a595442fcaac531f> 199 199 (daemon)
**End**
When downloading large data sets into core data, you need to account for lots of things. When it comes to memory management, the more popular issues are described below.
First and foremost, you need to save frequently, which allows you to purge the memory from the NSManagedObjectContext (aka MOC). At any time, you can see what objects the MOC has, by looking at the registeredObjects property of the MOC.
Normally, when you save a MOC, any objects that do not have a strong reference to them are removed from the MOC. Again, you can check after saving by looking at the registeredObjects. However, if you have relationships in your model, then the objects will contain strong references to each other, which creates a retain cycle. Thus, the objects will never be released until the retain cycle is broken.
You break retain cycles in a MOC by using refreshObject:object mergeChanges:NO. You can blow away all objects by calling reset but that is rather draconian, and you need to make sure you do not hold any references to managed objects when you do that.
Even if you don't have retain cycles between your managed objects, you could still be inadvertently retaining objects that you will never use again. This is where, even though you are using ARC, you still need to understand some memory management rules. Specifically, auto released objects. They will get automatically released, but not until the autorelease pool reclaims objects.
Thus, you should wrap your operations in your own autorelease pool. This is very simple:
#autoreleasepool {
// Unless you hold references elsewhere, objects allocated in here will be
// auto released when this scope ends.
}
If you have a thread doing your downloading, and you use a MOC of NSPrivateQueueConcurrencyType, the block you pass to performBlock gets automatically wrapped in an autorelease pool.