Since yesterday, when a power failure to the area stopped everything, I have been unable to run the sim. All apps build but fails to proceed with "Failed to connect to the simulator". No other apps appear to have been damaged. I have tried
All very confusing, but I much appreciate your assistance. This is what I get from running sudo dtruss -f sudo -u alansmith ./simulator >& trace.txt dtrace: system integrity protection is on, some features will not be available
dtrace: failed to execute sudo: dtrace cannot control executables signed with restricted entitlements
You're basically tracing all the low-level system calls that the simulator is making: writing to files, opening network ports, etc. Anything that requires permissions will be a system call, so the problem should be indicated somewhere in that trace.
For this to work you need to (temporarily) disable System Integrity Protection on your Mac.
Sorry, still struggling. I successfully executed "csrutil disable" and received "Successfully disabled Integrity Processing" message. Then rebooted - with long press of power button.
Then ran "sudo dtruss -f sudo -u alansmith ./simulator >& trace.txt" but still get :
dtrace: system integrity protection is on, some features will not be available dtrace: failed to execute sudo: dtrace cannot control executables signed with restricted entitlements
No worries. Yes, a long press of the power button, in either a PC or Mac, is like pulling the power plug on a desktop PC (or ripping out the battery from your MacBook if you could). It doesn't shut down cleanly and you could lose data, like the setting you just changed. Typically you want to restart/shutdown cleanly by asking the OS to restart.
Well here's something from the trace: /Users/YOURNAME/Library/Saved Application State/com.garmin.connectiq.simulator.savedState
Try deleting or renaming that folder and see if your problem disappears. Maybe the problem has something to do with persisted app state, since it's not the sim temp folder, the plugin or the SDK.
You probably want to go ahead and re-enable SIP as soon as possible, as it does serve an important role in protecting your Mac from hacking and/or malware.
There's also this: /Users/YOURNAME/Library/Logs/DiagnosticReports/simulator_2018-12-03-100620_YOURMACNAME.crash /Users/YOURNAME/Library/Application Support/CrashReporter/simulator_FD85745E-FE9A-5348-AB67-3B3AB02AE27C.plist
Files that you should be able to send to Garmin if you need further assistance.
I got all of that with a command similar to: grep simulator trace.txt
Long press. Yes, that's understood, but I would have expected a command such as csrutil to save the user input ....
Removed simulator.savedSate directory, restart Eclipse, still "Failed to connect to the simulator". But nice catch, thanks.
And yes, I have re-enabled SIP (even tho many commentators think it's a further example of Apple's patronising approach to users. Beware the onset of jailbreaking for Mac OS!)
Yeah, well I know some Mac users who are terrified of installing unsigned apps not found in the App Store, because they have to take steps to disable the built-in security and that's scary. And that's pretty much the whole point -- for security, but also to drive sales to the App Store..
Of course devs can still disable it, because we need to get work done. If the whole point of Windows wasn't support for legacy apps, Microsoft would've done the same thing with Windows 10.
In most cases, apps have no control over whether the stuff they write is fully committed to the hard drive/SSD/system flash/whatever. Most of the time, when an app writes something, the OS/drive controller says "Okay, finished writing!" but actually caches the data in RAM for performance reasons.
Even if those apps could call a system function to fully commit their changes, most don't bother because they expect the OS to do it for them at the appropriate time.
It's just like if you use printf() or NSLog() in XCode to print debug output to the console, you expect your output to be written at some point -- you don't bother to call fflush() to make sure it's actually written. But if your app crashes right after the printf(), you may actually have to call fflush() so you can see your debug output.
Anyway, sorry it's still not working for you. Hopefully someone from Garmin can help you out.
