My tvOS app uses Crashlytics for stack trace reporting. As it is a bitcode built app, I used the steps here to upload the missing dSYMs from iTunes Connect. However, while the Fabric dashboard has crossed off the missing dSYM entry, all of the stack trace data for our app is still reported as __hidden.... Not sure where we're going wrong.
For my build settings, I have:
Deployment Postprocessing -> Yes (for Release configuration)
Strip Linked/Installed Product -> Yes (for all configurations)
Related
I'm using NSSM to run a dotnet core app as a Windows service, which works really well.
However, I've noticed an error when I run nssm install MyAppName, which loads a window to set up the service. When I Select the executable to install, I notice that the following error is written to the console:
CreateDirectory : The system could not find the path specified. (3)
Could not initialize crash reporting DB
Can not init crashpad with status: CRASHPAD_DB_INIT_ERROR[23584]
registry_win.h:59:GetProtoFromRegistryValue Opening registry key Software\Google\DriveFS\Share failed with 0x2
I dont know much about NSSM nor Google DriveFS, but I'm wondering why I'm seeing this message - any ideas? My main concern is whether or not this is trying to access my Google Drive? Probably not - it seems a fairly reputable app, but I figure it's best to ask as someone will likely know better than me.
I've been trying to follow the
Setting Up Stackdriver Debugger for Java applications on Google Compute Engine, but am running into issues with Stackdriver Debug.
I'm building my .war file from a separate build server, then deploying it to my GCE server. I added the agent to the start command via /etc/defaults, and my app appears in the https://console.cloud.google.com/debug control panel. The version I set in the run command matches the revision that shows up in the source-context(s).json files.
However when I click open the app, I see the message that
No source version information was provided by the deployed application
I connected the app's git repo as a mirrored cloud repository, and can browse the source files in the sidebar of the Stackdriver Debug page. But, If I browse to a file and add a breakpoint I get an error that the error "File was not found in the executable."
I have ran the gcloud preview app gen-repo-info-file command, which created two basic json files storing my git repo and revision. Is it supposed to do anything else?
I have tried running jetty using both normal and extracted modes. If I have jetty first extract the war file, I can see the source-context.json filesin the WEB-INF/classes directory.
What am I missing?
https://github.com/GoogleCloudPlatform/cloud-debug-java#extra-classpath mentions
you can update the agentPath showing your WEB-INF/class directory.
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes
For multiple class paths:
-agentpath:/opt/cdbg/cdbg_java_agent.so=--cdbg_extra_class_path=/opt/tomcat/webapps/myapp/WEB-INF/classes:/another/path/with/classes
There are a couple of things going on here.
First, it sounds like you are doing the correct thing with gen-repo-info-file. The debugger agent should pick up the json files from the WEB-INF/classes directory.
The debugger uses fuzzy matching to find source files, so as long as the name of the .java file matches a file in your executable, you should not get that error.
The most likely scenario given the information in your question is that you are attaching the debugger to a launcher process, rather than your actual application. Without further details, I can't absolutely confirm that, though.
If you send us more details at cdbg-feedback#google.com, we can look more closely at your case to see if we can understand exactly what's happening, and potentially improve our documentation, since it sounds like you followed the docs pretty closely.
Can you help me get my crashes symbolicated?
In Xcode 7.3, Window -> Organizer -> Crashes, I have crash reports from my latest TestFlight builds. They were built on this Mac, and all the archives with the corresponding dSYMs are in the Archives tab. The app is divided into a number of frameworks and the main app, and many are a mix of Swift and Objective C. In the crash log I can see the name of the frameworks and app listed correctly, but all the entries for my frameworks and app are in hex. UIKit is symbolicated just fine.
When I look in iTunes Connect, it says "Yes" to "Includes Symbols" and allows me to download the dSYMs. When building, the "Debug Information Format" option was set to "DWARF with dSYM". I tried setting "Strip Debug Symbols During Copy"
and "Strip Linked Product" to "No" to see if that made a difference. It didn't.
I cannot find the symbolicatecrash app on my system, not even in /usr/bin or /Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/A/Resources/symbolicatecrash, but I have an older Xcode 5 where I could grab it. However, it does not resolve the symbols anymore.
I have the same problem in Instruments, if I profile my app, UIKit is symbolicated just fine, but my frameworks and app only show hex.
I know there have been a lot of posts about this, but I have going through them a lot from the 7.3 beta period and until now and have not found a solution
The location of symbolicatecrash has changed in Xcode 7.3:
/Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
After reading this:
https://developer.apple.com/library/content/technotes/tn2151/_index.html
you find out that the App Store is responsible for symbolicating crash reports that come from TestFlight – not Xcode. And it appears the App Store is very unreliable at doing it.
Here's a workaround.
Go to the Archives tab in the "Organizer" window and make sure that for whatever build you need to symbolicate a crash report for, you have clicked the "Download dSYMS..." button over on the right side of the page. This is required if you are uploading in BitCode.
Attach an iOS device so that it appears in the "Devices" window.
Select the device and click "View Device Logs".
Now, go back to the Organizer Window, select the "Crashes" tab and select one of the crashes that did not get symbolicated.
Right-click on it and select "Show in Finder".
Right-click on the revealed .xccrashpoint bundle and select "Show Package Contents".
Drill down into DistributionInfos -> all -> Logs.
Drag any of the .crash files into the left side of the "View Device Logs" pane open in the Devices window.
Wait a second or two for Xcode to symbolicate the crash.
Same here. Having a hard time finding the symbolicatecrash after upgrading to 7.3.
However, you can still use the atos though.
You can find the tutorial here Symbolicate crash in iOS8 with Xcode 6 .1
I do not upload symbols with my application, so the App Store cannot symbolicate for me. I used the following workaround to symbolicate all of the crashlogs that XCode downloads from the store. These instructions are for XCode 8. The paths for the symbolicate crash app will vary from version to version of XCode but the ideas should be the same in each version.
Place your symbols where the symbolicator can find them: Place your symbols (.dsym) file in your Archives directory. You can find this by going to Organizer, context clicking on an archive and choosing "show in finder". Navigate up to the Archives directory (e.g. /Users/USERNAME/Library/Developer/Xcode/Archives) and place your dsym file there. It can be in other locations as well, it's just that I've verified that this one works.
Download the crash logs: In XCode, make sure that you've downloaded the crashlogs for the build you want to symbolicate (Organizer->Crashes, click on your app and then choose the version of your app in the panel to the right of the list of apps).
Locate the crash logs on disk: In the panel that has the App Version and build number, context click on one of the crashes and choose "Show in Finder". Navigate up to the "Crashes Folder" and note this location e.g.: /Users/USERNAME/Library/Developer/Xcode/Products/com.company-name.Your-App/VERSION/Crashes
Setup DEVELOPER_DIR for symbolicatecrash on the command line: Open a terminal window and CD to the crashes directory from step 3 and set the DEVELOPER_DIR like this: cd /Users/USERNAME/Library/Developer/Xcode/Products/com.companyname.Your-App/VERSION/Crashes/
export set DEVELOPER_DIR=/Applications/Xcode.app/Contents/Developer
(this should be the location of the "Developer" directory inside of your XCode app bundle).
Locate the symbolicatecrash script: symbolicatecrash knows how to find your symbolicate crash logs using the dsym from step 1. Apple moves it around from version to version of xcode. You can find it like this: find /Applications/Xcode.app/ -name symbolicatecrash. In XCode 8, it is in /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash
Backup your crashes folder You may want to backup your crashes folder (/Users/USERNAME/Library/Developer/Xcode/Products/com.companyname.Your-App/VERSION/Crashes/)
Symbolicate all of your crashes: Be sure that you are still in the Crashes directory from step 4 and type
for i in `find . -type f -name \*.crash`; do cat $i | /Applications/Xcode.app/Contents/SharedFrameworks/DVTFoundation.framework/Versions/A/Resources/symbolicatecrash --output $i.sym; mv $i.sym $i; done;
This symbolicates each .crash file into an output file and then copies that back over the original, unsymbolicated file.
View Crashes Return to the crashes organizer and view the symbolicated crashes
I tried to copy symbolicatecrash file from xCode 7.2 and pasted it in xCode 7.3 in the following path:
/Applications/Xcode.app/Contents/SharedFrameworks/DTDeviceKitBase.framework/Versions/Current/Resources/
Am using Crasher script to symbolicate the crash reports How to use Crasher
According to the documentation of Xcode 9.0:
The Crashes Organizer symbolicates unsymbolicated logs, if they are
selected, using a local .dSYM indexed by Spotlight. (22550064)
You can check out more on this in Xcode's Documentation.
Upgraded Telerik in my ClickOnce application to version 2014.3.1202.40. (Never sure of the best way to do this. After the install, all my references to Telerik controls was broken and I had to remove all Telerik references in each of the projects and re-add them. So, I may be upgrading in the wrong way. But that's another matter.)
I deploy my app to a staging folder on my web server before moving to production. The app is signed with a commercial code signing certificate from Comodo that doesn't expire until 2019. I've uploaded new versions many times with no problem. But now, since I upgraded the Telerik controls, I can't download the and install the application. Here's what happens:
In Chrome, I enter the url: http://porpoiseanalytics.com/PorpoiseStaging/setup.exe
I get the "Not commonly downloaded" warning where I never got that before. I don't get any error on Firefox nor on IE.
If I tell Chrome to keep the file, I can start it. The installation starts on all the other browsers too.
About 3/4 of the way through the download of the files, Avast blocks it with DRep virus (I'm guessing lack of reputation). If I turn off Avast, it installs fine. ClickOnce install log shows an error: "Exception occurred loading manifest from file [application].exe: the manifest may not be valid or the file could not be opened."
Why is my application suddenly acting like it has no reputation when it's been downloaded for months with no problems. But, after I modify the application in VS2010 and then remove and re-add the Telerik dll's, I suddenly have no reputation. And what makes matters worse, is that now my production download located at ttp://porpoiseanalytics.com/PorpoiseDownload/setup.exe is suddenly acting the same way.
I admit I don't have a good enough understanding of reputation, signing, and clickonce. But I do know that whereas before we were fine, after deploying the application, we're flagged as malicious software. I made a few code changes in the program (not many), but I also replaced the Telerik dlls. Probably has something to do with signing and publishing, but I can't figure it out. Please help. Thanks.
I think I figured it out. Although I had signed the manifest in the main UI project (the installer), the executable was not signed. With some help, learned how to do that:
Download the Windows 7 SDK with signtool.
In Visual Studio, open project properties in the main UI project.
Open the Compile tab and click on the Build Events button.
In the post-build events, enter:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe" sign /f "$(ProjectDir)[name of code cert file]" /p "[password]" /t http://timestamp.comodoca.com/authenticode "$(ProjectDir)obj\$(ConfigurationName)\[exe name].exe
where [name of cert file] is the name of the code-signing cert file, such as private_key.pfk, and [password] is the password used when exporting the certificate (if % is included in the password escape it with %%, so pass%word would be entered as pass%%word), and [exe name] is the name of your primary project executable.
In other projects within solution, sign those by inserting a similar command line in the same post-build location:
"C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\signtool.exe" sign /f "$(ProjectDir)DAD_Code_Certificate.pfx" /p "<password>" /t http://timestamp.comodoca.com/authenticode "$(TargetPath)
Orignal Problem
My theory is that the original problem was caused because of a new feature in Avast 2015 that does a DomainRep (reputation?) check and if several criteria are all met, the alarm bells go off and it stops the download. Because my executable was not signed, it met all the requirements.
It is possible (although I really am not sure about this) that because of this DRep alarm, Google flagged the installer on our website as malicious, causing the red "not normally downloaded" warning when first starting the download.
At least, that's my best guess. Others will most certainly understand this better than me (and would have avoided it in the first place by signing the executable).
Official answer from Google Apps technical support (I'm on the Silver support plan - $150/month):
I replicated the issue you are describing and it looks to be a known
issue with Google Chrome, when trying to download an archive that has
an executable in it.
Please be advised that Google Chrome is outside the support scope of
Google Cloud, however the workaround is rather simple: when that
message appears you can click on the arrow to the right of that
message and chose "keep". This will download the file requested.
I have literally tried every single possible thing on every single post on this website and my app still gets rejected by the Invalid Binary Error. I am using a valid distribution certificate. Any idea? Using xCode 3.2.6 with ios 4.3. I have literally gone over the guide on the dev portal at least 20 times and I just need help!
Invalid Signature - Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose "Clean All" in Xcode, delete the "build" directory in the Finder, and rebuild your release target.