I've been dealing with a pernicious crash bug in my iPhone app, which is consistently reproducible in the version downloaded from the App Store, but not at all in the debug version. I have produced a workaround, which works by excluding the critical drawing code from running during a UIViewController animation.
The crash log indicates that there is an assert failure in CGPathAddLineToPoint.
The app uses the drawing functions CGContextMoveToPoint, CGContextAddLineToPoint, and CGContextStrokePath. The functions CGPathCreateMutable, CGPathAddLines, and CGContextAddPath are also used, but the app still crashes even in configurations that (should) avoid invoking them.
The crash happens consistently when lines are drawn on a view while its UIViewController is being presented (animated). Otherwise, the drawing works without issue.
I have confirmed in the debug version that every point of every line drawn is real and within the boundaries of the view.
The app crashes immediately on iOS7 when the drawing is attempted. On iOS5 and iOS6, the app stops responding for 30 seconds before crashing, leaving behind an "Unknown" crash log with no information.
The only cases I could find on the web similar to this problem were CGFloatIsValid assert failures in CGPathAddLineToPoint in OS X apps (including iPhoto crash logs posted to Apple's support forums).
I can't say much more about it because the app never crashes or even gives a warning in the debug version. Has anyone else encountered this bug? Is there a better way to resolve this issue?
You can view the workaround in action in the release version on the App Store. You can see that the line drawing on the graph is delayed until after the animation completes when you push the [Graph] button, when the calculator is in 2D mode.
The important part of the crash log (from an iPhone 5S running iOS 7.0.3, app armv7):
Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Triggered by Thread: 0
Thread 0 Crashed:
0 libsystem_kernel.dylib 0x3a5e11fc __pthread_kill + 8
1 libsystem_pthread.dylib 0x3a648a4f pthread_kill + 55
2 libsystem_c.dylib 0x3a592029 abort + 73
3 libsystem_c.dylib 0x3a571c67 __assert_rtn + 179
4 CoreGraphics 0x2fd566f5 CGPathAddLineToPoint + 149
5 (My App) 0x001464cd 0xd7000 + 455885
6 UIKit 0x324d4dd5 -[UIView(CALayerDelegate) drawLayer:inContext:] + 369
7 QuartzCore 0x3210aa75 -[CALayer drawInContext:] + 97
8 QuartzCore 0x320f4241 CABackingStoreUpdate_ + 1857
9 QuartzCore 0x321ce2e9 ___ZN2CA5Layer8display_Ev_block_invoke + 49
10 QuartzCore 0x320f3af1 x_blame_allocations + 81
11 QuartzCore 0x320f37a3 CA::Layer::display_() + 1115
12 QuartzCore 0x320d7365 CA::Layer::display_if_needed(CA::Transaction*) + 205
13 QuartzCore 0x320d6ffd CA::Layer::layout_and_display_if_needed(CA::Transaction*) + 21
14 QuartzCore 0x320d6a09 CA::Context::commit_transaction(CA::Transaction*) + 225
15 QuartzCore 0x320d681b CA::Transaction::commit() + 311
16 QuartzCore 0x320d0549 CA::Transaction::observer_callback(__CFRunLoopObserver*, unsigned long, void*) + 53
17 CoreFoundation 0x2fc9bf67 __CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION__ + 19
18 CoreFoundation 0x2fc998f3 __CFRunLoopDoObservers + 283
19 CoreFoundation 0x2fc99c3f __CFRunLoopRun + 735
20 CoreFoundation 0x2fc0446d CFRunLoopRunSpecific + 521
21 CoreFoundation 0x2fc0424f CFRunLoopRunInMode + 103
22 GraphicsServices 0x349382e7 GSEventRunModal + 135
23 UIKit 0x324b9841 UIApplicationMain + 1133
24 (My App) 0x000de723 0xd7000 + 30499
25 (My App) 0x000dde0c 0xd7000 + 28172
Several things:
Try opening the crash log on the machine from which you submitted the version in the app store. That version should have the archive containing the symbol file that you need to symbolicate the crash log.
If you only crash when you add lines to a path while your view controller is being animated onto the screen, why not add code to the completion block of your call to presentViewController:animated:completion: that invokes a method enabling drawing. Set up your view controller so drawing is disabled when it's first displayed, and gets enabled by the method call in the completion block.
To clarify (for people of the future), there is a workaround if your app is crashing during an animation, only in the App Store version, and the crash logs indicate an assert failure in CGPathAddLineToPoint. Just exclude all line-drawing code from running during the animation, and it won't crash.
Related
I experiencing a crash in my app:
Thread 0 name:
Thread 0 Crashed:
0 LogoQuizAC 0x0000000104705218 __hidden#563_ + 0 (__hidden#957_:0)
1 LogoQuizAC 0x0000000104705218 _hidden#18_ + 592 (__hidden#957_:135)
2 LogoQuizAC 0x000000010470503c __hidden#564_ + 48 (__hidden#456_:0)
3 LogoQuizAC 0x000000010470503c _hidden#18_ + 116 (__hidden#957_:135)
4 LogoQuizAC 0x00000001046fcd6c _hidden#17_ + 504 (__hidden#454_:96)
5 LogoQuizAC 0x00000001046fcea0 _hidden#20_ + 36 (__hidden#456_:0)
6 Foundation 0x0000000182770b20 __NSFireTimer + 68 (NSTimer.m:270)
7 CoreFoundation 0x0000000181355fa0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 (CFRunLoop.c:1807)
8 CoreFoundation 0x0000000181355ba0 __CFRunLoopDoTimer + 1064 (CFRunLoop.c:2415)
9 CoreFoundation 0x0000000181354ffc __CFRunLoopDoTimers + 328 (CFRunLoop.c:2575)
10 CoreFoundation 0x000000018134eee4 __CFRunLoopRun + 1936 (CFRunLoop.c:3090)
11 CoreFoundation 0x000000018134e21c CFRunLoopRunSpecific + 600 (CFRunLoop.c:3242)
12 GraphicsServices 0x0000000198f18784 GSEventRunModal + 164 (GSEvent.c:2259)
13 UIKitCore 0x0000000183d8eee8 -[UIApplication _run] + 1072 (UIApplication.m:3253)
14 UIKitCore 0x0000000183d9475c UIApplicationMain + 168 (UIApplication.m:4707)
15 LogoQuizAC 0x000000010453a404 main + 68 (RLockedCell.swift:21)
16 libdyld.dylib 0x000000018100e6b0 start + 4
I tried almost everything but can symbolicate the crash.
I tried using symbolicatecrash followed by these posts:
(_hidden#919_:0) inside crash symbolication file
Why aren't the crashlogs from Testflight symbolicating in Xcode?
Xcode Crash Organizer does Not Symbolicate .xccrashpoint Files
How to symbolicate crash log with Xcode 8?
how Symbolicate a crash file using xcarchive
How to symbolicate crash log Xcode?
But without any success.
What am I doing wrong? How can I figure out what causing the crash?
The good news that it is crashing in your code, not in Operating Systems or Library code, so you have a good chance to debug it. Your code that is crashing is running off a timer. Sometimes these bugs are seen because in testing, you are just testing the app. But in the real world, those timers fire when you are not expecting them.
For example, someone ran your app, then put it into the background when using another app, or for example they received a phone call whilst using the app. If you attach the full contents of the .crash file, it will give more information on the cause of the crash.
Another thing you can do is place asserts into your code, such as in your timer callback functions for each object you are relying on being non-null.
You may find that your app is trying to draw onto the screen but is in the background. This is a common reason for a crash seen in the field for games that use timers. That may sound like a generalisation but it is a suggestion to try and make you think differently about the real world environment your customers face which can the reason for the failure.
I'm getting a crash periodically with a gpus_ReturnGuiltyForHardwareRestart.
The crash is sporadic, and occurs in a complex multi-threaded app. Sample stack trace below.
It seems to occur (which is rare) when the UI and related handlers are being stressed (think hyperactive user making lots of gestures as quickly as the app and system will allow), with lots of resulting calls to behind-the-scenes and up-front rendering.
Researching gpus_ReturnGuiltyForHardwareRestart suggests this may be due to a buffer issue, e.g. a buffer overrun due to an incorect binding or failure to unbind.
gpus_ReturnGuiltyForHardwareRestart crash
(not relevant, but I did look: gpus_ReturnGuiltyForHardwareRestart)
My understanding is that a buffer gets corrupted in some way, and the crash happens sometime later when the corrupted buffer is accessed.
I've been through the code and made sure every bound buffer and texture is subsequently unbound to prevent unwanted/unintentional changes by later code; still getting the crash.
I did just come across these, suggesting the possibility of a bug in the OS:
iOS 9 Beta 4 crash: gpus_ReturnGuiltyForHardwareRestart (original poster indicated was fixed in 9 beta 5)
Re: OpenGLES driver crash in iOS9 Beta2/3
However, I'm currently testing on 9.3.4, so it seems this would be fixed.I've tried making sure all buffers are properly unbound after use, and tried periodic use of glFlush(), both without success.
Does anybody have experience with this, any knowledge on potential sources, means of tracking down causes, or fixes?
Stack trace:
Date/Time: 2016-08-11T20:20:40Z
Launch Time: 2016-08-11T20:15:22Z
OS Version: iPhone OS 9.3.4 (13G35)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0x1
Crashed Thread: 0
Thread 0 Crashed:
0 libGPUSupportMercury.dylib 0x0000000191bd9f28 gpus_ReturnGuiltyForHardwareRestart + 12
1 libGPUSupportMercury.dylib 0x0000000191bdaec4 gpusSubmitDataBuffers + 168
2 GLEngine 0x0000000195e9f1e4 gliPresentViewES_Exec + 172
3 GLEngine 0x0000000195e9f0fc gliPresentViewES + 80
4 OpenGLES 0x000000018576bc44 -[EAGLContext presentRenderbuffer:] + 68
5 NWFPApp 0x00000001001ef8fc -[NWFPIOSGLView renderNormalBuffers] (NWFPIOSGLView.mm:543)
6 NWFPApp 0x00000001001ef814 -[NWFPIOSGLView renderAll] (NWFPIOSGLView.mm:516)
7 NWFPApp 0x00000001001ee780 -[NWFPIOSGLView doInContext:] (NWFPIOSGLView.mm:135)
8 NWFPApp 0x00000001001ef770 -[NWFPIOSGLView drawView] (NWFPIOSGLView.mm:494)
9 NWFPApp 0x0000000100203cc8 -[NWFPGLChoreographer displayLinkEvent:] (NWFPGLChoreographer.m:128)
10 QuartzCore 0x000000018614022c CA::Display::DisplayLinkItem::dispatch() + 36
11 QuartzCore 0x00000001861400e0 CA::Display::DisplayLink::dispatch_items(unsigned long long, unsigned long long, unsigned long long) + 420
12 IOKit 0x0000000183885e54 IODispatchCalloutFromCFMessage + 368
13 CoreFoundation 0x00000001835ad030 __CFMachPortPerform + 176
14 CoreFoundation 0x00000001835c57d4 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 52
15 CoreFoundation 0x00000001835c4f0c __CFRunLoopDoSource1 + 432
16 CoreFoundation 0x00000001835c2c64 __CFRunLoopRun + 1796
17 CoreFoundation 0x00000001834ecc50 CFRunLoopRunSpecific + 380
18 GraphicsServices 0x0000000184dd4088 GSEventRunModal + 176
19 UIKit 0x00000001887ce088 UIApplicationMain + 200
20 NWFPApp 0x00000001002af1a0 main (main.m:30)
21 ??? 0x000000018308a8b8 0x0 + 0
In my app many crashes with the following log are reported very often, but even with several test devices and iOS versions I am not able to reproduce it. So there's no way to find the reason on Xcode. Because there's no step in the trace, that leads to my code, I cannot imagine any way to find the origin of it. The App itself is very complex and of course many Scroll Views, also embedded, are used.
Has anyone an idea where to start looking? Or has anyone had a similar problem before?
I'm very thankful for any help!
Best regards,
Florian
OS Version: iPhone OS 6.0.1 (10A523)
Report Version: 104
Exception Type: SIGSEGV
Exception Codes: SEGV_ACCERR at 0xd1d28fbc
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x392e65b0 objc_msgSend + 16
1 UIKit 0x35a839f7 -[UIScrollView(UIScrollViewInternal) _scrollViewAnimationEnded:finished:] + 135
2 UIKit 0x35a838e9 -[UIAnimator stopAnimation:] + 469
3 UIKit 0x35b1e257 -[UIAnimator(Static) _advanceAnimationsOfType:withTimestamp:] + 295
4 UIKit 0x35a83381 -[UIAnimator(Static) _LCDHeartbeatCallback:] + 53
5 QuartzCore 0x323d3071 CA::Display::DisplayLink::dispatch(unsigned long long, unsigned long long) + 161
6 QuartzCore 0x323d2fc9 CA::Display::IOMFBDisplayLink::callback(__IOMobileFramebuffer*, unsigned long long, unsigned long long, unsigned long long, void*) + 65
7 IOMobileFramebuffer 0x340befd7 IOMobileFramebufferVsyncNotifyFunc + 155
8 IOKit 0x35ee8449 IODispatchCalloutFromCFMessage + 193
9 CoreFoundation 0x339605db __CFMachPortPerform + 119
10 CoreFoundation 0x3396b173 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 35
11 CoreFoundation 0x3396b117 __CFRunLoopDoSource1 + 139
12 CoreFoundation 0x33969f99 __CFRunLoopRun + 1385
13 CoreFoundation 0x338dcebd CFRunLoopRunSpecific + 357
14 CoreFoundation 0x338dcd49 CFRunLoopRunInMode + 105
15 GraphicsServices 0x33f222eb GSEventRunModal + 75
16 UIKit 0x3596a2f9 UIApplicationMain + 1121
17 0x00005233 main (main.m:14)
I had the same crash. It turned out to be because we were animating a controller with [controller setContentOffset:newPt animated:YES], and we implemented the scrollViewDidScroll delegate method on the controller. Clicking a button on the screen let you advance to another controller, so if a user managed to click the button while the animation was in progress, we would hit the original poster's crash. The solution is simply to set the delegate to nil in dealloc.
The SIGSEGV signal is sent to a process when it makes an invalid virtual memory reference, or segmentation fault. (see Wikipedia)
So you are accessing an object that likely has been released. As this is an during an animation, maybe you defined a selector to be invoked after the animation finished or something like that? That would be were I would starting looking.
You might want to take a look at this thread: Is there a way to cancel an animated UITableView/UIScrollView setContentOffset:animated:?
That discussion suggests it might be a delegate that is dealloc'd before the scrollview sends the animation ended message.
My application is crashing when one of the views is purged from memory because of low-memory condition. At least this is what I understand from the crashlog. It happens on numerous screens but only when opening a Facebook dialog (using the Facebook SDK). Basically, looks like the system sometimes runs out of memory when we need to present a Facebook dialog (e.g. to let user post something on the Facebook timeline).
Date/Time: 2012-03-14 19:47:33.819 +0000
OS Version: iPhone OS 5.1 (9B176)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0x30000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x30f2bf78 objc_msgSend + 16
1 MyApp 0x00003c0e -LTBaseViewController viewDidUnload (LTBaseViewController.m:145)
2 MyApp 0x00004ea2 -LTBaseTableViewController viewDidUnload (LTBaseTableViewController.m:90)
3 UIKit 0x33766bd8 -[UIViewController unloadViewForced:] + 244
4 UIKit 0x338ae492 -[UIViewController purgeMemoryForReason:] + 58
5 Foundation 0x3071a4f8 __57-NSNotificationCenter addObserver:selector:name:object:_block_invoke_0 + 12
6 CoreFoundation 0x30e95540 ___CFXNotificationPost_block_invoke_0 + 64
7 CoreFoundation 0x30e21090 _CFXNotificationPost + 1400
8 Foundation 0x3068e3e4 -NSNotificationCenter postNotificationName:object:userInfo: + 60
9 Foundation 0x3068fc14 -NSNotificationCenter postNotificationName:object: + 24
10 UIKit 0x3387926a -UIApplication _performMemoryWarning + 74
11 UIKit 0x33879364 -UIApplication _receivedMemoryNotification + 168
12 libdispatch.dylib 0x36a12252 _dispatch_source_invoke + 510
13 libdispatch.dylib 0x36a0fb1e _dispatch_queue_invoke$VARIANT$up + 42
14 libdispatch.dylib 0x36a0fe64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
15 CoreFoundation 0x30e9c2a6 __CFRunLoopRun + 1262
16 CoreFoundation 0x30e1f49e CFRunLoopRunSpecific + 294
17 CoreFoundation 0x30e1f366 CFRunLoopRunInMode + 98
18 GraphicsServices 0x33fb6432 GSEventRunModal + 130
19 UIKit 0x336f5e76 UIApplicationMain + 1074
20 MyApp 0x00004818 main (main.m:16)
21 MyApp 0x000023b4 0x1000 + 5044
I checked and there are almost no memory leaks, e.g. when testing the app for an hour the total memory leaked was around 2-3Kb caused by some string-copying libraries. So I don't believe this is caused by the application. I guess that when the phone is not restarted for some time there are applications running in the background and when using Facebook SDK the memory becomes a problem and the system tries to recover the memory from random applications, including my application.
My question is, how can I prevent this crash from happening? How should I handle unloadViewForced on a view controller to make the app more robust in low-memory conditions? And lastly, am I right that this crashlog suggests the crash occurred because the system tried to free memory and my application didn't handle it properly?
Any help greatly appreciated.
What is most likely happening is that one of the objects being referred to and probably being released by LTBaseViewController viewDidUnload method is being doubly released. In fact, since the backtrace indicates that the crash is happing on line 145 of LTBaseViewController.m you should be able to quickly see which object is the culprit.
An iPhone app is crashing on the device but not on the simulator. So I'm trying to learn how to interpret the crash log. I read lots of forum posts saying that the symbolicated crash log shows a back trace that gives the method and line number of the calls leading to the crash but I don't see anything useful. Maybe I'm not looking at the symbolicated crash log. Here is the beginning of what I see:
Incident Identifier: 432A8974-1661-409F-B5A6-970148550A46
CrashReporter Key: db93147c0a70a5f4c60dc92f826e72d5a74477c8
Hardware Model: iPhone3,3
Process: Darken [57959]
Path: /var/mobile/Applications/CB27C10F-CD3B-4148-8321-2C251888B27B/Darken.app/Darken
Identifier: Darken
Version: ??? (???)
Code Type: ARM (Native)
Parent Process: launchd [1]
Date/Time: 2012-02-25 10:43:47.753 -0500
OS Version: iPhone OS 4.2.10 (8E600)
Report Version: 104
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x00000008
Crashed Thread: 0
Thread 0 Crashed:
0 libobjc.A.dylib 0x32716464 objc_msgSend + 16
1 UIKit 0x3245e6fe -[UIScrollView(UIScrollViewInternal) _scrollViewAnimationEnded] + 90
2 CoreFoundation 0x32071bb8 -[NSObject(NSObject) performSelector:withObject:] + 16
3 UIKit 0x3245e5b8 -[UIAnimator stopAnimation:] + 276
4 UIKit 0x323efbf2 -[UIAnimator(Static) _advance:] + 214
5 UIKit 0x323efb0e LCDHeartbeatCallback + 10
6 GraphicsServices 0x35474362 HeartbeatVBLCallback + 86
7 IOMobileFramebuffer 0x34739bf4 IOMobileFramebufferVsyncNotifyFunc + 68
8 IOKit 0x348e5e64 IODispatchCalloutFromCFMessage + 192
9 CoreFoundation 0x32070be0 __CFMachPortPerform + 204
10 CoreFoundation 0x320686f8 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION__ + 20
11 CoreFoundation 0x320686bc __CFRunLoopDoSource1 + 160
12 CoreFoundation 0x3205af76 __CFRunLoopRun + 514
13 CoreFoundation 0x3205ac80 CFRunLoopRunSpecific + 224
14 CoreFoundation 0x3205ab88 CFRunLoopRunInMode + 52
15 GraphicsServices 0x354724a4 GSEventRunModal + 108
16 GraphicsServices 0x35472550 GSEventRun + 56
17 UIKit 0x323c7d1a -[UIApplication _run] + 406
18 UIKit 0x323c5884 UIApplicationMain + 664
19 Darken 0x000029d6 0x1000 + 6614
20 Darken 0x00002998 0x1000 + 6552
... Threads other than 0 listed here
Is anything here useful for finding out which line of my code led to the crash? Darken is the name of the application -- I already knew that. The only method name I recognize is UIApplicationMain but the crash didn't happen when the app was first launched -- I was running it about a minute and doing dozens of functions before the crash.
You may want to try and set NSZombieEnabled to YES in your project and let it crash with your device running in debug. It should stop at the line of code causing your crash. Your error looks like it is an EXC_BAD_ACCESS which usually means you were trying to access some deallocated memory.
You won't get a line number from a crash dump (unless you compiled your app with -g and run in GDB, but I doubt it since you don't seem to know what these are at all).
You ARE looking at the symbolicated crash dump: you DO have the names of the functions in the call stack. The crash occurs in the last called (topmost) function, which is objc_msgSend. That means you're not properly balancing your alloc/retain/copy methods with autorelease/release, and the messenger function tries to access already freed/corrupted/nonexistent memory, hence the crash (EXC_BAD_ACCESS is similar to a segfault, in fact you'll get one of these when you make such a mistake).
So my advice is, triple check your code for method calls modifying the reference count.