I'm using BugSense to track crashes from an iOS App. Recently I noticed problems symbolicating stack traces from live usage.
The problem is that Apple introduced address space randomization with iOS 4.3 so that the stack address of interest cannot solely be used to retrieve the correct methods that caused the crash.
Currently I'm trying to get the correct address by calculating
symbol address = slide + stack address - load address
I already have slide and stack address but from my understanding the load address can only be found in the crash report which I cannot get via BugSense.
The stack trace looks like
0 CoreFoundation 0x342723e7 + 162
1 libobjc.A.dylib 0x3bf63963 objc_exception_throw + 30
2 CoreFoundation 0x3427229d + 0
3 Foundation 0x34b48fa3 + 90
4 UIKit 0x360b5bd9 + 7640
5 MyApp 0x000c6e99 0xb3000 + 81561
6 UIKit 0x3623c2ff 0x3607e000 + 1827583
7 UIKit 0x361b8737 0x3607e000 + 1287991
8 UIKit 0x361a9869 0x3607e000 + 1226857
9 UIKit 0x361a97ad 0x3607e000 + 1226669
10 CoreFoundation 0x34247941 0x341b0000 + 620865
11 CoreFoundation 0x34245c39 0x341b0000 + 613433
12 CoreFoundation 0x34245f1d 0x341b0000 + 614173
13 CoreFoundation 0x341b923d CFRunLoopRunSpecific + 356
14 CoreFoundation 0x341b90c9 CFRunLoopRunInMode + 104
15 GraphicsServices 0x37d9733b GSEventRunModal + 74
16 UIKit 0x360d52b9 UIApplicationMain + 1120
17 MyApp 0x000b61bf 0xb3000 + 12735
18 MyApp 0x000b4a08 0xb3000 + 6664
Is there another way to symbolicate this address or to get the respective load address?
The load address is 0xb3000.
Luckily you have the symbols stripped from your app binary, otherwise this wouldn't be visible.
Also this crash happened because of an exception being thrown, so the crash report should give you a Last Exception Backtrace showing where the actual exception happened and the actual exception reason. It is likely that the call in line 5 of the posted stack trace doesn't give you a lot of information on that. The crash information you are getting looks pretty limited :(
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 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 using the TestFlight SDK and have received several crash reports identical to this one. However, I'm having trouble understanding it, and what the underlying cause of the crash is from the reports?
Exception
SIGSEGV
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60...
Exception reason
SIGSEGV
Stacktrace
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
3 Foundation 0x33750d1c -[NSError dealloc] + 60
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
8 MyAppName 0x000b7168 MR_swapMethodsFromClass + 18076
9 CoreData 0x35e0dbc0 developerSubmittedBlockToNSManagedObjectContextPerform + 88
10 libdispatch.dylib 0x335974b6 _dispatch_client_callout + 22
11 libdispatch.dylib 0x33598dca _dispatch_main_queue_callback_4CF$VARIANT$up + 226
12 CoreFoundation 0x31e79f3a __CFRunLoopRun + 1290
13 CoreFoundation 0x31decebc CFRunLoopRunSpecific + 356
14 CoreFoundation 0x31decd48 CFRunLoopRunInMode + 104
15 GraphicsServices 0x36e092ea GSEventRunModal + 74
16 UIKit 0x320db2f8 UIApplicationMain + 1120
17 MyAppName 0x00099122 main (main.m:17)
18 MyAppName 0x000990d7 start + 39
Additional details:
Users report this crash happens 1-2 seconds after the app starts
The app uses Core Data and MagicalRecord (which is where the MR_swapMethodsFromClass method comes from)
I can't reproduce this issue on any test devices when running from Xcode (iPhone 3GS, iPhone 4, or iPhone 5) running various iOS versions (iOS 5.1, 6.0, 6.1)
EDIT
Still working on solving this issue... I've been able to recreate it (but not with a debugger attached).
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.
Let's walk through it:
0 MyAppName 0x0013faba testflight_backtrace + 382
1 MyAppName 0x00140708 TFSignalHandler + 264
That's TestFlight. This is after the crash has happened, so it's certainly not the cause.
2 libsystem_c.dylib 0x32862e92 _sigtramp + 42
This is the point at which we caught the crash. "sigtramp" is the signal "trampoline." That's a fancy way of saying "I caught a signal (crash) and now I'm going to bounce to somewhere else in the code."
3 Foundation 0x33750d1c -[NSError dealloc] + 60
Ah. This is important. We crashed while deallocating an NSError. That means the NSError was over-released or under-retained.
4 libobjc.A.dylib 0x39230488 _ZN12_GLOBAL__N_119AutoreleasePoolPage3popEPv + 168
5 CoreFoundation 0x31de9440 _CFAutoreleasePoolPop + 16
6 Foundation 0x33751f7a -[NSAutoreleasePool drain] + 122
Sad… it manifested while draining the autorelease pool. That means the actual bug could be a long way from here. But at least we know the type of the object. NSZombies could be of use to try to find the specific object.
7 CoreData 0x35e0a4b2 -[NSManagedObjectContext save:] + 1210
And the autorelease pool was draining during a MOC save. That suggests it's probably related to your Core Data code. It's at least where you'd look first.
The things to remember are:
The bug is almost certainly in your code.
If it's not in your code, it's probably in Magical Record
Do not assume it is in Core Data. That is the least likely place for the bug given this stack.
Here's the strangest part-- if a user has an older version of the app and installs an update (distributed via Test Flight), they get this error.
However, if they first delete the old app and install the update, the error doesn't occur.
Probably in your upgrade code then. Most likely in the Core Data migration stuff. Audit every use of NSError in that area of code. Eliminate all compiler and analyzer warnings. And try NSZombies if its reproducible.
You should try to add a model version to your data model. It worked for me, i had a similar Magical-Record-related issue.
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.
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.