I have an iOS app, written in Swift in Xcode 6.2, using the Parse SDK 1.7.0. I've gone through the Parse Quick Start instructions for setting up crash reporting (including ParseCrashReporting.enable() in the AppDelegate), but it seems that my run script is having an issue. The error is: App "/Users/ben/Library/Developer/Xcode/DerivedData/MyApp-ahydphsjgdgefbhcdodokcmofehe/Build/Products/Debug-iphonesimulator/MyApp.app.dSYM" wasn't found. Command /bin/sh failed with exit code 1.
According to this, it seems that Xcode is not creating the dSYM file. In my Build Settings > Build Options I have changed Debug Information Format to "DWARF with dSYM file" for both Debug and Release. (Previously, Debug was set to "DWARF")
Should I change anything else in the Build Options?
Also, could this be the issue? export DWARF_DSYM_FILE_SHOULD_ACCOMPANY_PRODUCT=NO
Here is my run script:
export PATH=/usr/local/bin:$PATH
cd $PROJECT_DIR/parse
parse symbols "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
Thank you in advance for any ideas about how to fix this.
Edit: Thanks to the answer from #udjat, I was able to run my app and run script (below) without the app crashing. And thanks to some bug fixes from Parse, the test crash reports are functioning now as well, though there is still a significant delay.
New run script:
echo "Parse Crash Reporting"
export PATH=/usr/local/bin:$PATH
CLOUD_CODE_DIR=${PROJECT_DIR}/parse
if [ -d ${CLOUD_CODE_DIR} ]; then
cd ${CLOUD_CODE_DIR}
parse symbols MyApp --path="${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
echo "Finished uploading symbol"
else
echo "Unable to upload symbols"
fi
Crash test in AppDelegate:
func crash() {
NSException(name:NSGenericException, reason:"Everything is ok. This is just a test crash.", userInfo:nil).raise()
}
func application(application: UIApplication, didFinishLaunchingWithOptions launchOptions: [NSObject : AnyObject]?) -> Bool {
ParseCrashReporting.enable()
dispatch_after(
dispatch_time(DISPATCH_TIME_NOW, Int64(5.0 * Double(NSEC_PER_SEC))),
dispatch_get_main_queue(),
{ () -> Void in
self.crash()
});
}
After reading through the Facebook link #jairobjunior posted, I found the fix (at least for myself) in Árni Jón Reginsson's answer and modified a bit.
In the Parse document, your run script is:
export PATH=/usr/local/bin:$PATH
cd YOUR_PATH
parse symbols "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
Instead, change it to:
echo "Parse Crash Reporting"
export PATH=/usr/local/bin:$PATH
CLOUD_CODE_DIR=${PROJECT_DIR}/ParseCloudCode(or wherever yours is)
if [ -d ${CLOUD_CODE_DIR} ]; then
cd ${CLOUD_CODE_DIR}
parse symbols YOUR_PARSE_APP_NAME --path="${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
echo "Finished uploading symbol"
else
echo "Unable to upload symbols"
fi
And it takes a lot more than "up to one minute" for your crash reports to show up on Parse (took me more than 15 minutes). If it finished uploading, it will be there, you just need to be patient.
There is an open thread about this issue here: https://developers.facebook.com/bugs/587774604658221/
I am having the same problem, even trying to do manually it says file "wasn't found", but the file is there. One thing that I've noticed is that .dSYM is not a file, for me it seems to be a folder/package.
I found this to work..
export PATH=/usr/local/bin:$PATH
cd YOUR_PATH
parse symbols AppName -p "${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
Adding the app name and the -p to the parse line
Sorry I don't have the reputation to comment so I'll leave this as an answer.
I got the exact problem. Also using the latest Parse SDK. It is suspected that it is the problem of the latest CLI 2.0.0 since developers start getting the issues you're getting (and also I'm getting) after updating to 2.0.0
Subscribe to this Facebook bug reporting post to get the solution in the future.
https://developers.facebook.com/bugs/466020460223551/
At this moment it seems like the problem is from the SDK. So there is nothing to do except waiting for Parse to fix this.
(Thanks #jairobjunior for introducing me the Facebook bug reporting page!)
just wanted to let you know you're not alone: although my DSYM seems to upload fine, no crash reports from any of my apps ever show up on parse.com, no matter what I do. I've spent an hour checking every setting... all looks good. I use the same test crash as you do...
So, please update here if you find a solution to crashes not showing up on parse.com. thanks!
In my case the problem was probably create by changing the project name, anyway using the following script made it :
parse symbols MyAppName --path="${DWARF_DSYM_FOLDER_PATH}/${DWARF_DSYM_FILE_NAME}"
Where MyAppName is was what I found in the parse/config file :
{
"applications": {
"MyAppName": {
"applicationId": "....kjsldgjslkgjslkgj...",
"masterKey": "....lksjmll242dg2d1g2..."
},
"_default": {
"link": "MyAppName"
}
}
}
Related
I want to extract the feature from audio using OPENSMILE with the following cmd in Linux:
/iflytek/workplace/tools/opensmile/SMILExtract -C
/iflytek/workplace/tools/opensmile/config/gemaps/eGeMAPSv01a.conf -I
/iflytek/ytwei7/Coding/最新音频处理版本/音频切分/cut/1.wav -csvoutput
/iflytek/ytwei7/Coding/最新音频处理版本/特征提取/corpus/1.csv
And get an error:
(ERROR) [1] in configManager : ConfigType::findFieldH: referenced base field with name
'Percentiles.quartiles' not found!
I update GCC-version from 4.8 to 9.3 and compile opensmile in another way,the problem has gone. I don't know why but it works.
I recently stepped down my electron application removed knex and sqlite since it was painfully complicated to creating a rebuild on windows also when i made an executable for windows sqlite database didn't seem to work. Linux executable worked fine with sqlite guessing the same with mac.
To use sqlite i had rebuilt the application using electron-rebuild. In order to clear the rebuild i did rm -rf node_modules && npm install
I have eventually decided to use IndexDB using dexie.
However now when i try to run my program from npm i get
ERROR:buffer_manager.cc(488)] [.DisplayCompositor]GL ERROR :GL_INVALID_OPERATION : glBufferData: <- error from previous GL command
How do i fix this, why is it happening ?
NB: The application works just fine but this error i the terminal is just annoying and i have no idea why its happenning
Do a test,
electron /path/to/the/app [You will get that Error]
Try
electron --disable-gpu /path/to/the/app [You mayn't get that Error]
The fix was to add "--disable-gpu" to the command-line to force the
web view not to use gpu features. I was able to accomplish this in an
electron app by editing the package.json file in app root and changing
the line like "start": "electron ." to "start": "electron .
--disable-gpu"
Refer https://github.com/electron/electron/issues/7834#issuecomment-275802528
Based on Sudhakar RS answer , I made a script in my package.json to not use GL
here is my package.json
{
...
"scripts": {
"start": "electron --disable-gpu .", // --disable GL ERROR and use CPU
...
}
...
}
Then in your terminal run
npm run start
I had the same error running electron-quick-start but not when running electron-boilerplate.
Investigating the error I found this question and for me also, starting with "electron --disable-gpu ." prevents the error message. But I didn't have to do that with electron-boilerplate. So, comparing the two I traced the difference to the inclusion of electron-debug in electron-boilerplate and, ultimately, to this: process.stderr.fd.
Thus far, the minimal change I have found sufficient to avoid the error is:
diff --git a/main.js b/main.js
index 3508c8e..7df262b 100644
--- a/main.js
+++ b/main.js
## -2,6 +2,8 ##
const {app, BrowserWindow} = require('electron')
const path = require('path')
+process.stderr.fd;
+
// Keep a global reference of the window object, if you don't, the window will
// be closed automatically when the JavaScript object is garbage collected.
let mainWindow
So, now I am trying to understand what process.stderr.fd; does and how it prevents the error message from appearing. It seems odd that merely getting the file descriptor of stderr would prevent the error but evidently it does.
I am also curious about the relative merits of disabling the GPU Vs getting the file descriptor.
edit: it is sufficient to get the stream with process.stderr; it is not necessary to get the file descriptor.
My solution for issue:
"dev": ".electron-vue/dev-runner.js --disable-gpu"
Unexpected argument '/Users/saylanc/yazario-ios-app/Pods/ServiceAccount.json'
usage: /Users/saylanc/yazario-ios-app/Pods/FirebaseCrash/upload-sym [-h] [-v] [-w|-e]
Command /bin/sh failed with exit code 2
I am getting this error, I followed the guide at the official firebase page.
My bash script :
GOOGLE_APP_ID=1:xxxxx:ios:xxxx
"${PODS_ROOT}"/FirebaseCrash/upload-sym "${PODS_ROOT}"/ServiceAccount.json
Make sure you're using the latest version of FirebaseCrash. It looks like you have an older version of upload-sym.
Our app wasn't crashing, but we were getting the following warning."Unable to find service account JSON file: ${SERVICE_ACCOUNT FILE}"
What fixed it for us was to change the script to:
"${PODS_ROOT}"/FirebaseCrash/upload-sym "${SRCROOT}"/ServiceAccount.json
Thought that might help.
Days ago I built the application for Android, zero problems, but now, when I try to do the same for iOS (obviously not the same commands) I always receive an error.
I use the following command:
cordova platform add ios
And I get the following error:
Downloading cordova library for ios...
Download complete
Creating ios project...
Error: An error occured during creation of ios sub-project.
File "/Users/xxxxx/.cordova/lib/ios/cordova/3.3.0/bin/update_cordova_subproject", line 31
print __doc__
^
SyntaxError: invalid syntax
at /usr/local/lib/node_modules/cordova/src/platform.js:282:30
at ChildProcess.exithandler (child_process.js:641:7)
at ChildProcess.EventEmitter.emit (events.js:98:17)
at maybeClose (child_process.js:743:16)
at Socket.<anonymous> (child_process.js:956:11)
at Socket.EventEmitter.emit (events.js:95:17)
at Pipe.close (net.js:466:12)
I tried also with:
phonegap build ios
But I get the same error and I don't know how to fix it. I've been looking on the Internet and I found some guy with the same problem but nobody could help him.
I run the commands with sudo, that isn't the problem.
I recently got the same error.
My problem was that I'm using Python3 by default. print in Python2 is a statement wherease in Python3 it's a function.
.cordova/lib/ios/cordova/3.3.0/bin/update_cordova_subproject has a shebang that calls /bin/python.
I had to replace #!/bin/python with #!/bin/python2.7 to use python2.7 on this script.
I have the exactly same problem with you. However, the way replace "#!/bin/python with #!/bin/python2.7" doesn't work for me.
Inspired by the explanation of Matthieu Riegler, I change print __doc__ to print(__doc__) in line 31 and print line to print(line) in line 97. Eventually, it works.
I have tried to install OTP14B02 on OpenSolaris and i get the following error at calling ./configure:
muzaaya#opensolaris:~/Desktop/software and data/otp_src_R14B02# ./configure
Ignoring the --cache-file argument since it can cause the system to be erroneously configured
Disabling caching
Usage: cd [-LP] [directory]
Or: cd [ options ] old new
configure: error: cannot find install-sh or install.sh in export/home/muzaaya/Desktop/software and data/otp_src_R14B02/erts/autoconf /export/home/muzaaya/Desktop/software and data/otp_src_R14B02//export/home/muzaaya/Desktop/software and data/otp_src_R14B02/erts/autoconf
What could be causing this problem and how can i overcome it?
Whenever I see a space in a path on any system all kinds of bells an whistles goes off, it shouldn't matter but sometime it does. Have you tried moving to a path without spaces in it?
Also, as it says, it failed to find /export/home/muzaaya/Desktop/software and data/otp_src_R14B02/erts/autoconf/install.sh, does that file exist on your system?