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.
Related
I am setting up Firebase Crash Reporting on my iOS App. I have imported the necessary json files and set up the shell script. However, when I click run on the simulator, I get 11 errors all say about the same thing. Here are two of them:
warning: dump_syms: /var/folders/5l/20by_c_57fb7jhv3jh72jw9m0000gn/T/com.google.FirebaseCrashReporter.TAlixfZc/**App Name**.dSYM/Contents/Resources/DWARF/**App Name**: in compilation unit '/Users/mikelehen/firebase/firebase-client-objc/Firebase/Firebase/Utilities/FUtilities.m' (offset 0x28a2e): `
warning: dump_syms: /var/folders/5l/20by_c_57fb7jhv3jh72jw9m0000gn/T/com.google.FirebaseCrashReporter.TAlixfZc/**App name**.dSYM/Contents/Resources/DWARF/**App Name**: the DIE at offset 0x28fc1 has a DW_AT_abstract_origin attribute referring to the die at offset 0x2940f, which either was not marked as an inline, or comes later in the file `
When I try to run it on my iPhone I get only four issues.
Also, my name is not mikelehen which is for some reason in one of the issues.
After following the instructions on Firebase's website about simulating a crash, I never get the log output about the crash being uploaded.
Any idea of what I'm doing wrong here?
Edit:
Here is the script that is in my build phases:
JSON_FILE="../**App Name**/ServiceAccount.json"
GOOGLE_APP_ID=1:**App ID**
defaults write com.google.SymbolUpload version -integer 1
JSON=$(cat "${JSON_FILE}")
/usr/bin/plutil -replace "app_${GOOGLE_APP_ID//:/_}" -json "${JSON}" "$HOME/Library/Preferences/com.google.SymbolUpload.plist"
"${PODS_ROOT}"/FirebaseCrash/upload-sym
Try:
Build Phases --> Run Script
Click Run script only when installing
Those warnings are not harmful for the most part. The dump_syms utility that ships with the Cocoapod is not fully productized, so it reports errors using file names of the person who compiled it last (mikelehen in this case). We are actively looking into alternatives to dump_syms as the warnings are distracting.
As mentioned by Robert, the warnings are innocuous. Here are some suggestions that might help you out if you're having issues getting a crash to upload:
1) Make sure the debugger is not attached when you cause the crash to occur. It will intercept the exception, and nothing will get reported. So compile your program, hit stop in the debugger, manually launch the app (in either the simulator or the device), trigger the crash, then relaunch the app (without the crash so the error has time to report).
2) You should see a log message that Firebase Crash Reporting was initialized. If this is missing, make sure you've included the Firebase/Crash pod and called [FIRApp configure];.
3) Within 15 seconds, you should see another message indicating the report has been successfully sent. Be sure to wait at least 15 seconds. Reports are uploaded after a delay to avoid interfering with your app startup.
4) After the report has been uploaded, there is a delay of up to 20 minutes before data shows up in the web console.
5) If you're not using cocoapods, make sure you've added the ObjC linker flag in your Other Linker Settings in your target's build settings.
The dump_syms warnings generated are not harmful and are generated when symbol files are uploaded. So if you want to avoid warnings every time you build, you can create two targets; debug and release.
Then just disable the option of 'Run script only when installing' for Debug and enable it for release.
This will upload the symbol files.
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'm trying to run my Cocos2d-x app built in Xcode 5.0.2 on a 4th generation iPod Touch running iOS 6.1.5. I don't have any third party libraries in the project yet, other than Cococs2d-x.
When I hit run, the behavior is inconsistent. Xcode builds the whole project without a hitch, but then gives me one of two errors at random. It doesn't strictly alternate, and it isn't tied to whether it's a clean build. It's just a coin toss.
Sometimes, I get not one, but two Could not inspect the application package. errors.
Sometimes, on the other hand, Xcode gives me this error:
The Info.plist for application at /Users/me/Library/Developer/Xcode/DerivedData/myapp/Build/Products/Debug-iphoneos/myapp.app specifies a CFBundleExecutable of ${EXECUTABLE_NAME}, which does not exist
I've found several reports of similar errors around the internet, but they usually say it specifies an executable of "(null)", and their solutions don't work for me. The most popular solution is, frustratingly, to set CFBundleExecutable (AKA "Executable File") to ${EXECUTABLE_NAME} in my Info.plist, which it is.
Any ideas? This is really weird.
UPDATE: Okay, I set Executable File to my literal product name, and now I'm down to the two "Could not inspect the application package." errors. The other error no longer comes up. That's some progress, anyway...
You could try using:
CFBundleExecutable ${PRODUCT_NAME}
in your info.plist
Sometimes deleting the ${EXECUTABLE_NAME} and manually putting it in works also. It sounds as if there's some corruption going on with the build and it's ignoring the parameter.
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.
I am creating an installer using the Adobe AIR captive runtime feature. Normally, the compiler generates a directory for me with all the necessary files that I then use to generate an .msi installer with.
Before, I could just double click the .exe file in this generated directory and the application would already work. (Good way of checking whether the generated files are valid).
I have now stumbled into the situation where I double-click the .exe file and nothing happens. No error message, no logs, nothing. The .exe file just exits immediately.
I have dug up and older installer of my app and tried to run this, the resulting install works fine. But once I replace my SWF file in the install directory with a new build of my app, I once again have the problem.
So, obviously SOMETHING in the Main.swf doesn't agree with the .exe file, but since there are no error messages or whatever it is extremely hard to figure out what the problem is.
The application runs fine from the IDE, by the way, the problem only occurs when I use it in combination with the captive runtime output.
Has anybody ever experienced something similar? And how were you able to figure out what was going on? Is there some secret place where AIR perhaps logs some errors, or is there a way to convince it to output some kind of error log?
You need to create a blank file with no extension called "Debug" (I used textedit and simply removed the extension manually). Put that in the META-INF/AIR/ folder, next to application.xml. This will cause the Air runtime to run in debug mode.
From what I can tell, if there are any fatal errors (e.g. a certain failover .swz file can't be loaded) then at least you'll be able to see what's going on.
Did you manage to make this work?