I have an app on the App Store that is crashing. I have tried several of the solutions on SO to symbolicate my app, using at different times the Organizer, the Terminal, and Instruments. Nothing has worked so far - the lines in the reports from the methods in my app are never symbolicated, even when the lines for Apple methods are. After looking around for a while, it seems as though this might have something to do with the app name, which is along the lines of "Angie's List" - with both an apostrophe and a space. It is too late to change the app name now as it is live on the store. I haven't seen a solution to this anywhere and would appreciate a shove in the right direction.
Usually the app name doesn't matter, unless there is a bug in the symbolication script which I doubt. Did you check if you have the correct dSYM available?
If you scroll down your latest crash log, check the 1st line below Binary Images, it will look like this
0x1000 - 0x24cfff +YourApp armv7 <f6012c517d783486ab53e45d948b92a2> /var/mobile/Applications/A8EC3C1F-44AF-169A-BC0E-FBBC0F04CDF5/YourApp.app/YourApp
f6012c517d783486ab53e45d948b92a2 is the UUID of the executable the caused the crash.
You can find the correct dSYM using the terminal as follows:
mdfind "com_apple_xcode_dsym_uuids == F6012C51-7D78-3486-AB53-E45D948B92A2"
The string F6012C51-7D78-3486-AB53-E45D948B92A2 is the above string reformatted to uppercase and 8-4-4-4-12 groups. I guess this command will not return anything.
If you have a dSYM (e.g. in an .xcarchive), you can check its UUID in the terminal as follows:
dwarfdump --uuid YourApp.app.dSYM
If symbolication doesn't work automatically, you can try to do it manually by following the instructions posted here: iOS crash reports: atos not working as expected
If the application has special characters like spaces or apostrophe's in it, the default Apple toolchain will not be able to symbolicate it. The reason is that the tool otool, which being used in the toolchain, can't handle that. No matter how you pass the filename. So to fix this, you have to do the following:
Rename the dSYM package and remove all special chars, e.g. from My App's.app.dSYM to MyApps.app.dSYM
Open the content inside the package and navigate down to Contents/Resources/DWARF
Rename the file in there as you did above
Now try again. Best way to avoid all this: NEVER use special chars in your apps name. If you want the adjust the name that appears on the screen, use CFBundleDisplayName or the corresponding plist entries.
Related
I'm having a problem with breakpoints in the source code of a specific library / framework (new to Xcode - i'm not sure what the correct term is) in a fairly large iOS project. I have all the code for this library. Breakpoints are working fine everywhere else, but in this one specific library, all breakpoints are ignored.
I can put a breakpoint in a function called from within one of those source files, and it will trigger, but then the callstack shows "__lldb_unnamed_function" for the location in the file i'm interested in, as if the symbols have been stripped.
I have the following settings for the library in question
Generate Debug Symbols = YES
Strip Debug Symbols During Copy = NO
Strip Linked Product = NO
Dead Code Stripping = NO
I have been using a lot of #ifdefs to test alternate implementations of a few functions so i thought some stuff might be getting marked as dead code by accident (hence that last setting). I already tried clean/rebuild. I tried completely removing the app from the target iPhone. I tried deleting intermediate file folder under
/Library/Developer/Xcode/DerivedData
The code is definitely executing because all my NSLog calls show up properly.
I don't have much experience with Xcode so i'm hoping i'm just missing something simple
Thanks
Some part of your build process must be stripping this binary. If you were generating an unstripped binary with no debug information, then you would see full symbol names in backtraces and the like, you just wouldn't have debug information for them.
The only good way to figure out who is doing this is to look at the full build log in Xcode, and expand each of the stages and grub through all the build stages to figure out who is doing this. You expand the stages by hovering over each build line on the RHS and you'll get a disclosure dingus that looks like a bunch of lines on a page; click that to see the real commands.
Another way to finesse this may be to build the dSYM for this framework (by setting the Debug Format to "DWARF + dSYM".) That should get made before anything gets stripped, so unless whoever is stripping this is being awfully clever this should preserve the debug information.
I've read through a number of similar questions here about Parse Crash Reporting, and got a couple of hints that helped. But I am still unable to get the symbol file uploaded.
I added the script to XCode exactly as per instructions on the Parse Website. When the app builds, the script seems to run, and all the right messages are being displayed.
and
I added the time-delayed forced Exception to the app, in the suggested place. I ensured that CrashReporting was enabled. I added the Parse framework to the project via CocoaPods; it's there, and the app compiles without error or warning. I did the sequence of one crash, restart, second crash, wait a few minutes, refresh the Parse Dashboard.
But Parse thinks otherwise:
OK, fine. So i did a manual push of the file, via CLI from Terminal. First attempt failed because I wasn't uploading the DWARF file. Corrected that. Now it says it cant' find the file or directory.
Here's my folder on my machine, where the file is located:
And here's the command line, with the command and result:
So the CLI maybe is thinking that the filename isn't a file; I tried changing the name by adding a ".bin" extension.
Then I got a different error: "Do not understand symbol files at:" followed by the full path to the file. I even tried enclosing the full path in single quotes, inside the double quotes; same not-found error.
I have the latest Parse CLI downloaded. I am running the command "parse symbols -p " from the app's Cloud Code directory (an existing directory that had been set up earlier to use other Parse Cloud Code features).
What else to add? Running XCode 6.4, Objective-C app, I checked various other Build Settings to ensure that symbols were being generated. The file is 30Mb in size and opening it reveals what is clearly a binary file, whose contents do look like they're symbols from a compiler - recognizable names of classes, etc.
This is just a test app, and I'm testing out the Parse crash reporting, rather than signing up for another service, like New Relic or any of the other ones; I figure, I'm using Parse for other stuff, why not use its Crash Reporting...
Anyone have any idea what I'm doing wrong here? I just can't see it.
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/
After cleaning everything in Xcode to Submit my app to iTunes Connect, I've reached an error that I cannot find an answer for.
The full error is:
Unable to Parse application Info.plist for validation. Please make
sure your Info.plist contains no embeddedcontrol characters, is del
formed, and is encoded in a UTF-8 compatible encoding.
Im creating the project with UNITY 3D, and everything works okay on my iPod and iPhone, but after I build it to archive and submit either from Organizer or Application Loader I get this error.
Can someone please Help??
I had this error, and it turned out to be an inadvertent space in one of the fields. But the key to resolving these errors is to view the info.plist file in a text editor. By careful examination, you are likely to be able to find the non-conforming character/field.
It's probably a BOM character or something else you can't see.
Try converting the document to UTF-8 without BOM
Also, make sure your line endings are all \n (LF) and not \r\n (CRLF). That should fix it.
I'm not sure what text-editors you have, but you can do this with TextWrangler which is Free.
Another possibility is that you have some other special character (like an & or < or >) that it doesn't like, but I'd suspect this isn't the case.
Try opening your Info.plist in a plain text editor and look for characters that may be out of place. If you have other similar apps, you can compare both plain text .plist files which may lead you to the problem.
Oddly enough, I had a project which exhibited this very error and in my case, swapping "Icon Files (iOS 5)" for the predecessor "Icon Files" made the difference. Remember that the older Icon Files requires the icons to be of the standard naming conventions: Icon.png, Icon#2x.png, Icon-72.png, Icon-72#2x.png, etc.
I can't explain why this change produces the different results which leaves me to believe its a bug in Apple app validation.
I need to debug the startup for an ios application on an actual device... and by start up I mean the very first instruction that is is executed when the OS hands control over to the app. Not "main". Also, this application doesn't have any symbols (ie. the debug information isn't available.. yet). I don't care if I have to debug at the CPU instruction level. I know how to do that (done it for over 30 years). I want the debugger to stop when control is about to transfer to the app. When I use the Attach|by Name command and run, it just says "Finished running".
Oh, and this application was not built in XCode. It is, however an application I built, signed and provisioned and moved to the device. The application does run since I can see the console output. Just in case you're thinking I'm some hacker trying to debug someone's application.
How's that for a tall order? I'll bet nobody can answer this... I've not been able to find any information on how I could do this with an XCode-built project. I wonder if it is simply not possible or "allowed" by the Apple overlords?
What do you say, Stack Overflow gods?
UPDATE: I should clarify something. This application is not built with any commercially available or open-source tool. I work with a tools vendor creating compilers, frameworks, and IDEs. IOW, you cannot get this tool... yet. In the process of bootstrapping a new tool chain, one regularly must resort to some very low-level raw debugging. Especially if there are bugs in the code generated by the tools.
I'm going to answer my own question because I think I've stumbled upon a solution. If anyone has anything more elegant and simple than this, please answer as well. On to the steps:
Starting with a raw monolithic iOS executable (not a bundled .app, but the actual binary mach-o file that is the machine code).
Create a new like-named empty Xcode project. Build and run it on the device.
Locate the output bundle's .app folder.
Copy the above raw iOS executable over the existing one in the .app bundle's folder.
The application will now have an invalid signature and cannot be deployed and run.
Run codesign against the app bundle (you can find out the command-line by running xcodebuild on the above Xcode project).
In the bundle's .app folder, run otool -h -l on the binary image. Locate the LC_UNIXTHREAD load command and find the value associated with the 'pc' register. This is address where the os loader will jump to your application. If this address is odd, then these are Thumb instructions otherwise it will be ARM (I think that's how it works).
Add a symbolic breakpoint (I used GDB instead of LLDB) and enter the address as '*0x00001234' as the symbol.
Select Product|Perform Action|Run Without Building.
Assuming that GDB is able to evaluate the breakpoint expression and set the break point, and you've selected Product|Debug Workflow|Show Disassembly When Debugging, the process should break at the very first instruction to be executed in the application.
You can now single step the instructions and use the GDB console to get/set register values.
Your question does not make sense - main is the entry point into the application. It is the first code that should be encountered, unless possibly you have initialize() overridden for some classes (but even then I think main would get hit before the runtime).
I think you are seeing some kind of odd error on launch and you think you want to set a breakpoint on entry to catch it, but far more likely what would help you is to describe the problem on launch and let one of the 4000 people who have seen and fixed the same crash help you...
However, if you really want to use GDB to break on an application with no symbols (but that you launch from XCode) you can have GDB break on an assembly address as per:
How to break on assembly instruction at a given address in gdb?
To find the address of main (or other methods) you can use tool or atos, some examples in this question:
Matching up offsets in iOS crash dump to disassembled binary
ADDITION:
If for some reason XCode cannot launch your application for debugging, you could also jailbreak and install GDB on the device itself which would give complete control over debugging. If XCode can launch you application I see no reason why being able to break at an arbitrary memory address does not give you the ability you seek...
One solution for applications with webviews is to run them in the iOS Simulator, and connect to that with the remote-debugger in macOS Safari. This is off-topic but maybe the one or other could benefit.
http://hiediutley.com/2011/11/22/debugging-ios-apps-using-safari-web-inspector/
Or use NetCat for iOS... not the most perfect solution, but at least you see what's going on.