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.
Related
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.
I'm running my ios app in ipad 1, the following crash happen sometime while app is running, i don't know where the crash happen. This mostly happen in ios 5.1.1 . Here the crash log,
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: KERN_INVALID_ADDRESS at 0xf0000008
Crashed Thread: 0
Thread 0 name: Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0 libobjc.A.dylib 0x3387ef78 objc_msgSend + 16
1 UIKit 0x333ffa3a -[UIViewController unloadViewForced:] + 254
2 UIKit 0x335473a6 -[UIViewController purgeMemoryForReason:] + 58
3 Foundation 0x3507a4f8 __57-[NSNotificationCenter addObserver:selector:name:object:]_block_invoke_0 + 12
4 CoreFoundation 0x35c2c540 ___CFXNotificationPost_block_invoke_0 + 64
5 CoreFoundation 0x35bb8090 _CFXNotificationPost + 1400
6 Foundation 0x34fee3e4 -[NSNotificationCenter postNotificationName:object:userInfo:] + 60
7 Foundation 0x34fefc14 -[NSNotificationCenter postNotificationName:object:] + 24
8 UIKit 0x335120e6 -[UIApplication _performMemoryWarning] + 74
9 UIKit 0x335121e0 -[UIApplication _receivedMemoryNotification] + 168
10 libdispatch.dylib 0x33ffb252 _dispatch_source_invoke + 510
11 libdispatch.dylib 0x33ff8b1e _dispatch_queue_invoke$VARIANT$up + 42
12 libdispatch.dylib 0x33ff8e64 _dispatch_main_queue_callback_4CF$VARIANT$up + 152
13 CoreFoundation 0x35c332a6 __CFRunLoopRun + 1262
14 CoreFoundation 0x35bb649e CFRunLoopRunSpecific + 294
15 CoreFoundation 0x35bb6366 CFRunLoopRunInMode + 98
16 GraphicsServices 0x33951432 GSEventRunModal + 130
17 UIKit 0x3338ecce UIApplicationMain + 1074
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct? How to find where the crash happen? Any suggestions.
As i understand from crash log, crash not happen due to my code. It's due low memory. Is that correct?
No, that's not correct.
Low memory is being reported, but your view controller is not responding properly. The most common cause of this is a retain cycle - see UIViewController purgeMemoryForReason: Crashing on iOS 5. In that answer, the retain cycle is in SVPullToRefresh , but yours could be elsewhere. The most common cause of retain cycles is not setting a delegate property to weak.
Once you figure out where the issue is, you can set breakpoints in viewDidUnload and ``didReceiveMemoryWarning`, simulate a memory warning, and step through your code to find the error.
Symbolication
Additionally, this crash report isn't symbolicated. Typically you'll want to symbolicate your crash report first. For example, see these lines:
18 MY Game 0x00079a90 0x75000 + 19088
19 MY Game 0x00079a50 0x75000 + 19024
In this case, as pointed out by Kerni, those two will just show start and main, so they won't help you in this instance. But generally, you should symbolicate your crash reports. (Search for "Xccode symbolicate crash logs" if you don't know how to do this.)
I'm using crittercism to get crash report on my app.
It's working pretty well but I got a crash with a stacktrace which is not really helpful.
0 libobjc.A.dylib 0x3b16c5b0 objc_msgSend + 16
1 Foundation 0x33d6b0f5 __NSThreadPerformPerform + 461
2 CoreFoundation 0x33429683 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 15
3 CoreFoundation 0x33428ee9 __CFRunLoopDoSources0 + 213
4 CoreFoundation 0x33427cb7 __CFRunLoopRun + 647
5 CoreFoundation 0x3339aebd CFRunLoopRunSpecific + 357
6 CoreFoundation 0x3339ad49 CFRunLoopRunInMode + 105
7 GraphicsServices 0x36f712eb GSEventRunModal + 75
8 UIKit 0x352b0301 UIApplicationMain + 1121
9 myapp 0x00024c2f main (main.m:14)
The crash is symbolicated but there is no information to point me at the exact place of the crash.
I think it could be an object released too soon, but since it's a random bug and I don't know where it happen its really hard to track it down.
How do I convert this stacktrace or the crash report to a human readable one?
This crash is almost exactly identical with my main headache-causing crash at the moment, and I don't know what to do about it. The only change in my crash log is main (main.m:6) instead of your main (main.m:14).
So far I've found this:
SIGABRT crash on __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
Rejected iPhone app has strange crash logs
The accepted answers suggests that it could be related to misuse of performSelector.
This guy also has the same crash, but with no suggested solution:
http://comments.gmane.org/gmane.comp.handhelds.phonegap/24494
There are other, similar crash logs out there that have a curious addition:
...
CoreFoundation 0xXXXXXXXX -[NSObject performSelector:withObject:] + XX <- additional line
Foundation 0xXXXXXXXX __NSThreadPerformPerform + XXX
CoreFoundation 0xXXXXXXXX __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + XX
...
Which again suggests that it's related to performSelector, but that's still speculation.
In one of our iPhone apps, we have gotten a few Crashlytics crashes that we have, so far, been unable to reproduce. However, on closer inspection, I noticed a bit of a trend...
Crash 1: -[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 10%
Crash 2: -[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 8%
Crash 3: HostBase::lock()
Free RAM: 8%
Crash 4:-[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:]
Free RAM: 22%
Does the amount of free RAM mean anything? Can we be sure that these are actual crashes and not our app getting killed by the OS due to low memory? Does Crashlytics send crash reports if the app crashes while in the background?
Added a couple stack traces...
Exception Type: SIGSEGV, Nav Crashes
0 libobjc.A.dylib
objc_msgSend + 15
1 UIKit ✭
-[UINavigationTransitionView _notifyDelegateTransitionDidStopWithContext:] + 274
2 UIKit
-[UIViewAnimationState sendDelegateAnimationDidStop:finished:] + 158
3 UIKit
-[UIViewAnimationState animationDidStop:finished:] + 50
4 QuartzCore
CA::Layer::run_animation_callbacks(void*) + 208
5 libdispatch.dylib
_dispatch_client_callout + 22
6 libdispatch.dylib
_dispatch_main_queue_callback_4CF$VARIANT$mp + 224
7 CoreFoundation
__CFRunLoopRun + 1290
8 CoreFoundation
CFRunLoopRunSpecific + 356
9 CoreFoundation
CFRunLoopRunInMode + 104
10 GraphicsServices
GSEventRunModal + 74
11 UIKit
UIApplicationMain + 1120
Exception Type: SIGSEGV, HostLock crash
0 libobjc.A.dylib
objc_msgSend + 15
1 CFNetwork ✭
HostBase::lock() + 14
2 CFNetwork
DispatchHost::performInvocation(void const*) + 12
3 CFNetwork
__setupTCPConnection_block_invoke_2 + 290
4
...
libsystem_network.dylib
__tcp_connection_notify_complete_block_invoke_1 + 18
7 libsystem_c.dylib
_pthread_wqthread + 294
8% memory can be a lot, I highly doubt that this is an issue. I don't know if they send crashes while running in the background, you have to ask them directly since their SDK is not open source.
Both exception stack traces you added hint at a memory problem.
The first one looks like it tries to call a delegate at the end of an animation of an object, which does not exist any more.
The second one looks like a similar problem, where the completion block is accessing an object that is gone. So you might check your blocks for such patterns.
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.