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.
Related
I'm trying to get backtrace symbol like Xcode listout as below
*** First throw call stack:
(
0 CoreFoundation 0x018865e4 __exceptionPreprocess + 180
1 libobjc.A.dylib 0x016098b6 objc_exception_throw + 44
2 CoreFoundation 0x01923903 -[NSObject(NSObject) doesNotRecognizeSelector:] + 275
3 CoreFoundation 0x0187690b ___forwarding___ + 1019
4 CoreFoundation 0x018764ee _CF_forwarding_prep_0 + 14
5 Foundation 0x0124036c __NSFireDelayedPerform + 372
6 CoreFoundation 0x01844c46 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22
7 CoreFoundation 0x0184462d __CFRunLoopDoTimer + 1181
8 CoreFoundation 0x0182c698 __CFRunLoopRun + 1816
9 CoreFoundation 0x0182bb33 CFRunLoopRunSpecific + 467
10 CoreFoundation 0x0182b94b CFRunLoopRunInMode + 123
11 GraphicsServices 0x02c249d7 GSEventRunModal + 192
12 GraphicsServices 0x02c247fe GSEventRun + 104
13 UIKit 0x0037c94b UIApplicationMain + 1225
14 CrashHandler 0x000088ad main + 141
15 libdyld.dylib 0x06244725 start + 0
16 ??? 0x00000001 0x0 + 1
)
libc++abi.dylib: terminating with uncaught exception of type NSException
I'm trying to extract symbol from NSException as below code. and less information only available.
-(void)handleException:(NSException*)exception
{
[exception callStackSymbols]//I've written this into file.
}
I've got output as below
*** First throw call stack: (
0 CoreFoundation 0x326bd2bb <redacted> + 186
1 libobjc.A.dylib 0x3a33b97f objc_exception_throw + 30
2 CoreFoundation 0x326c0e07 <redacted> + 170
3 CoreFoundation 0x326bf531 <redacted> + 392
4 CoreFoundation 0x32616f68 _CF_forwarding_prep_0 + 24
5 Foundation 0x32fcb277 <redacted> + 450
6 CoreFoundation 0x326925df <redacted> + 14
7 CoreFoundation 0x32692291 <redacted> + 272
8 CoreFoundation 0x32690f01 <redacted> + 1232
9 CoreFoundation 0x32603ebd CFRunLoopRunSpecific + 356
10 CoreFoundation 0x32603d49 CFRunLoopRunInMode + 104
11 GraphicsServices 0x361b62eb GSEventRunModal + 74
12 UIKit 0x34519301 UIApplicationMain + 1120
13 CrashHandler 0x0007f421 main + 116
14 libdyld.dylib 0x3a772b20 <redacted> + 0
)
How to decode <redacted> symbol?
Reference and Understanding:
I've refer SO post1, SO post2 but It need dSYM file and we have to manually decode as like testflight.. Without dSYM file, how to do this?
Symbolication is the process of translation a memory address to a symbol that contains all or some of the following elements:
class name
method name
file name
line number
When symbolicating on the device with the app symbols being part of the app binary, only class name and method name can be retrieved. It is not possible to get file name and line number this way.
When symbolicating using the app dSYM, it is possible to get all data, as long all information is available when building the app. E.g. when using third party static libraries, file name and line number might be missing for those calls.
<redacted> symbols can only show up for system calls when symbolicating system framework addresses on the device. The reason the class name and/or method name doesn't show up is an iOS memory optimization. Explanation for this can be found here: https://devforums.apple.com/thread/171264
To symbolicate these addresses, you need to have the iOS symbols of the iOS version and CPU architecture that was used to create the stack trace on the computer that is symbolicating the report.
It is possible to get these symbols as part of Xcode or by connecting a device of the specific iOS version and CPU architecture to Xcode, which will then fetch the symbols. Note that e.g. for iOS bugfix versions that do not come with an updated SDK, the only way to get the symbols is using a device.
Symbolication on a computer can be done using Xcode organizer or manually using the symbolciatecrash.pl script which is part of Xcode manually in the terminal.
For symbolication to work with Xcode or the script, you need a full crash report which contains lots more information than your posted stack trace.
To use atos to manually symbolicate the frame addresses of your report, you'll also need the load address for each binary that a frame references, e.g. from Foundation, CoreFoundation, UIKit. The shown stack trace doesn't provide this information. There are multiple posts here on StackOverflow how to use atos manually.
There is no way to symbolicate the trace without a dSYMbolication file.
You could try to build your code with the option not to strip debug symbols but I'm not sure.
Also implementing a crash handler is a very delicate task that I would leave to pro's ;)
Yet you can give it a try and probably learn new things.
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 have been getting rather strange crash reports from my live app with stack traces like the following:
Thread 0: Crashed: com.apple.main-thread
0 libobjc.A.dylib 0x38af7942 realizeClass(objc_class*) + 117
1 libsystem_malloc.dylib 0x390dbef5 szone_malloc_should_clear + 1376
2 libobjc.A.dylib 0x38af976f lookUpImpOrForward + 74
3 libobjc.A.dylib 0x38af1feb _class_lookupMethodAndLoadCache3 + 34
4 libobjc.A.dylib 0x38af1db9 _objc_msgSend_uncached + 24
5 UIKit 0x30e571bf __57-[_UIDelayedPresentationContext beginDelayedPresentation]_block_invoke + 26
6 libdispatch.dylib 0x38fd9d07 _dispatch_client_callout + 22
7 libdispatch.dylib 0x38fe2803 _dispatch_source_invoke$VARIANT$mp + 262
8 libdispatch.dylib 0x38fe073d _dispatch_main_queue_callback_4CF$VARIANT$mp + 188
9 CoreFoundation 0x2e3ef819 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 8
10 CoreFoundation 0x2e3ee0ed __CFRunLoopRun + 1300
11 CoreFoundation 0x2e358c27 CFRunLoopRunSpecific + 522
12 CoreFoundation 0x2e358a0b CFRunLoopRunInMode + 106
13 GraphicsServices 0x3302c283 GSEventRunModal + 138
14 UIKit 0x30bfc049 UIApplicationMain + 1136
This is rather mysterious because neither the main thread nor any of the other live threads in the reports seem to imply that this is caused by my code, though of course I am skeptical of this.
This seems to be a rather common crash according to the number of reports I receive from Crashlytics, yet I have not been able to reproduce it on my own devices. I suspect this is probably related to some memory management issues because the various crashes always end up being some bad pointers being sent messages.
This always happens on this thread and following the -[_UIDelayedPresentationContext beginDelayedPresentation]_block_invoke call. This is obviously a private class being referenced from within some Apple framework, however I am at a loss to figure out exactly which one could be calling this.
The app is an educational game and I suspect this could be related to the GameKit API (particularly the Game Center authentication dialogs).
All of these crashes have been happening exclusively on iOS 7 and on iPad only. The app is universal so it is interesting to see that iPhone users seem to be unaffected.
Does anybody have any previous experience with these private classes that could give me some hints?
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.
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.