I am trying to debug some concurrency code and when I log [NSThread callStackSymbols]; the console shows most of the symbols I am interested in as <redacted>.
Is there a way to get around this during runtime? I have deleted the device symbols folder but Xcode re-symbolication didn't seem to fix the issue.
There are a few other questions on here but they all seem to be trying to solve this on crash files.
How can I see the method names for framework symbols in the debug console?
I am running Xcode 5.
You get all symbols showing up only:
while debugging
when generating a full crash report and symbolicate that.
symbolicating the addresses manually using atos with the corresponding dSYM or system symbols on disk (you need to load address for each framework and binary to do that, also due to Address space layout randomization. Only having callStackSymbols doesn't reveal those). See iOS crash reports: atos not working as expected
The <redacted> symbols are a
Memory optimization. The <redacted> symbol names are stored on disk only, which saves some physical memory and lots of virtual address space in every process.
See https://devforums.apple.com/thread/171264
To sum up: you can NOT get all system symbols showing up using any calls during runtime. Instead you need to create a full crash report by letting the app crash and analyse the stack traces from those.
Related
I am looking for a way to symbolicate external app symbols (iOS) inside my own application (macOS), assuming I have the DSYM and system symbols.
Xcode symbolicates both app addresses as well as system framework addresses (UIKit, Foundation, etc.)
atos requires an image file and can symbolicate addresses from that image.
I am looking to symbolicate a large number of addresses in my own app. The addresses represent stack traces at various points in time. I would like to symbolicate the system framework addresses as well.
I found atosl, which uses dwarf.h and libdwarf.h to reimplement atos to varying degrees of success—however this seems like a very low–level approach.
Are there any other ways to symbolicate a large number of addresses at once?
Here is symbolication I use in tests (requires XCTest): https://github.com/avito-tech/Mixbox/blob/db3206c95b71f35ae6032ff9b0baff13026608f4/Frameworks/TestsFoundation/Reporting/FileLineForFailureProvider/StackTrace/ExtendedStackTraceEntryFromStackTraceEntryConverterImpl.swift
I use the code to highlight failures in tests in Xcode without requiring testers to pass file: StaticString = #file, line: UInt = #line everywhere. The code is less readable with this boilerplate, and also there is not much reason for such boilerplate, because ideally Xcode should be able to highlight stacktrace of test failure...
Note that there is an issue. If you do not have sources on the machine that executes the code, it doesn't symbolicate. Maybe it can be fixed quickly, I didn't even tried.
Also there are comments in the code about other options: atos, lldb, CoreSymbolication. I think CoreSymbolication is what you want to use. The solution I gave you is simple, more dependent on XCTest, less configurable, has some other flaws.
I'm trying to symbolicate a crash dump for an iOS app buit using Xamarin.iOS. I am seeing a lot of warning about not being able to find symbols for system binary images such a Foundation, and the output from symbolicate is ultimately missing most of the information that I need.
I'm following the process described here. I have put MyApp.app, MyApp.app.dSYM, and the crash log into a directory and run symbolicate -o crash.txt "crashreport.crash" "MyApp.app". The output crash.txt contains no symbols, and I see a lot of errors in the symbolicate console output. For example:
Finding Symbols:
.fetching symbol file for Foundation--[undef]
Searching []...-- NO MATCH
Searching in Spotlight for dsym with UUID of e596bd80bcc83f15aca36a7ef014f457
Running mdfind "com_apple_xcode_dsym_uuids == E596BD80-BCC8-3F15-ACA3-6A7EF014F457"
#dsym_paths = ( )
#exec_names = ( )
Did not find executable for dsym
## Warning: Can't find any unstripped binary that matches version of /System/Library/Frameworks/Foundation.framework/Foundation
The full output is at http://pastebin.com/W1KP1iTR
I have used dwarfdump to verify that the UUID in MyApp.pSYM is the same as the one in the crash dump.
I'm using Xamarin studio 5.7.1 on with xcode 6.1.1.
Can anyone suggest what is going wrong here?
Apple's symbolicate tool requires that you add all executables and mach-o binaries to Spotlight database prior to querying for symbols.
This of course a tedious job that is required. I could never find how to remove it from the index, or to know what the queue has been completed and the binary with its UUIDs are indexed.
Plug: I wrote this symbolicate-pro tool.
Here's a program I wrote for TestFairy (the company). It's called symbolicate-pro and it has a few key differences that Apple's symbolicate:
It does not require any indexing.
You can specify directories where your iOS symbols are located.
It's 10x faster.
And if you get otool compiled for another OS, it can run on other platforms than Mac.
TestFairy uses it for its production and is updating when iOS changes the crash reports.
You can find it on github at: https://github.com/testfairy/symbolicatecrash-pro
Hope this helps ;)
I'm investigating how to create a server side iOS crash report symbolication server like Crashlitics or Crittercism or HokeyApp, from I can see, they only ask the user to upload the .dSYM file then they are able to symbolicate the crash report, I'm wondering how they archive it? Apple's standard symbolicatecrash command needs the app binary and the .dSYM file being provided together:
Symbolication - resolving stack trace addresses to source code methods and lines - requires the application binary that was uploaded to the App Store and the .dSYM file that was generated when that binary was built. This must be an exact match - otherwise, the report cannot be fully symbolicated. It is essential that you keep each build distributed to users (regardless of the details of that distribution) with its .dSYM file.
Any one knows the detail? Thanks.
Symbolication is the process of translating stack traces into a human-readable form by mapping hexadecimal addresses to function names using symbol file. In other words, Symbolication can be defined as the process of de-obfuscating code symbols with debug symbols removed to both reduce package size and make it harder to reverse engineer. Apteligent automatically symbolicates crashes once you have uploaded your app’s symbol file.
For Apple applications, stack traces are reported in hexidecimal characters. Symbolication allows developers to convert these hex strings into human-readable text.
For more information please refer to and http://support.crittercism.com/articles/knowledge_base/How-does-iOS-Symbolication-work and https://www.apteligent.com/developer-resources/symbolicating-an-ios-crash-report/
MyApplication creates a personalized crash report using the NSException instance. The app retrieves the callStackSymbols array and adds them to a text file.
If you notice on the crash report, instead of getting a line like this:
libsqlite3.dylib 0x30531ce4 0x30506000 + 179428
I'm getting a line like this one
29 MyApplication 0x00059260 MyApplication + 4704
Looks like instead of getting 2 addresses, I get "MyApplication" in the middle.
Atos is not working with the first address.
You get the symbolicated results, since your app binary contains the debug symbols, so calling callStackSymbols can resolve the addresses right away. The only missing part is the line numbers, which isn't possible to get automatically with the symbols being part of the app.
The three number values are: Address = Base Address + Offset. This means the first address is enough to get the symbol. The Base address is the start address of the binary/framework. Mostly when symbolication is done, the first address is also changed to be relative to the framework address instead of being absolute. The app binary memory area usually starts at 0x1000. This can be viewed in a crash reports binary images section, and it can be different to 0x1000 due to new memory features in newer iOS versions.
So for now simply use the give address in the 3rd column and add 0x1000 to the value when invoking atos.
In general I suggest using a framework based on PLCrashReporter, which will give you all information for a crash report. Including all threads and binary images in a standard crash report format and also works in the App Store.
I'm trying to use the OpenGL ES Analyzer for my iPad application and I can't get it to show me any symbols from my code in the extended detail pane's stack trace. I see the names of UIKit and UIApplication and other Apple supplied frameworks in the stack trace, but the portion of the stack trace that represents calls into my code just shows up as instruction pointer values, and there are no symbols whatever.
When I run the same app in Xcode 4 I can debug into my code without problem, all symbols are there, etc. So I believe the application is compiled correctly in this regard.
Do others out there have this problem? The information this analyzer is collecting would be extremely useful if I could see where it my code these calls are being made...
Any pointers / workaround very much appreciated.
-Eric
Well, figured this out myself eventually, so just for completeness and for anyone else who runs into this:
It is necessary to have dSYM debugger output, i.e. "DWARD with dSYM file" in the "Debug Information Format" setting in the project.
I had changed this to be just DWARF as creating the dSYM was taking a long time each build cycle.