I was trying to see which syscall ps uses to get the command line of a process on OS X 10.11 (El Capitan), and ran into the following error:
# dtruss ps -p 43520 -o args
dtrace: failed to execute ps: dtrace cannot control executables signed with restricted entitlements
Googling resulted in the suggestion that making a copy of ps would allow me to bypass this, but that didn't work for me. Why can't I run dtruss on arbitrary binaries anymore, and is there any way for me to restore the old behavior?
The issue has to do with the code signature. If you make a copy and then re-sign it with your own identity (or, presumably, any non-Apple identity), then dtrace will attach to it just fine.
$ mkdir ~/temp
$ cp /bin/ps ~/temp/
$ codesign -f -s `whoami` ~/temp/ps
$ sudo dtruss ~/temp/ps -p 43520 -o args
cannot control executables signed with restricted entitlements
Security Integrity Protection ('rootless') is now preventing dtruss from operating here.
You can disable it by booting into Recovery mode, but it looks like dtrace has specifically been blocked regardless of the state of rootless, as can be seen in the source code if you search for "dtrace cannot control".
You can also see from the comments in Pcreate:
/*
* <rdar://problem/13969762>:
* If the process is signed with restricted entitlements, the libdtrace_dyld
* library will not be injected in the process. In this case we kill the
* process and report an error.
*/
Related
I ran sudo -s in the OSX terminal and now it is defaulted to running as root.
Is there a way to undo this?
On Unix Type operating systems, all you have to do is type in the exit command this should exit root and return to the user you were currently running under before entering the command.
You can also hit Command+D and that should return you to the user you were running as before the command as well.
The bounty expires in 6 days. Answers to this question are eligible for a +50 reputation bounty.
Charlie Parker is looking for a more detailed answer to this question:
suggested answer didn't work, error:
Suggested accepted answer doesn't work for me. This is what I tried:
cd ~ cp /usr/bin/find find codesign --remove-signature ./find sudo dtruss ./find … error:
codesign --remove-signature ./find sudo dtruss ./find dtrace: system integrity protection is on, some features will not be available dtrace: failed to execute ./find: Could not create symbolicator for task
I wanted to trace the system calls made by the find command to debug some performance issues however I could not figure out how to do this on Mac OS X Yosemite. How can I trace system calls for an arbitrary program similarly to what strace does on FreeBSD? I am especially interested in tracing file-system related calls.
Suggested accepted answer doesn't work for me. This is what I tried:
cd ~
cp /usr/bin/find find
codesign --remove-signature ./find
sudo dtruss ./find …
error:
codesign --remove-signature ./find
sudo dtruss ./find
dtrace: system integrity protection is on, some features will not be available
dtrace: failed to execute ./find: Could not create symbolicator for task
Under current versions of macOS, executables under paths covered by SIP (like /usr/bin) cannot be traced.
You can bypass this by making a copy of the executable in your home directory and tracing the copy:
cp /usr/bin/find find
codesign --remove-signature ./find
sudo dtruss ./find …
You needed to remove the code signature from the new find executable, otherwise SIP still notices that a system file is being accessed (credit: #Anmol Singh Jaggi).
You can use dtruss like in
sudo dtruss find ~/repo -depth 2 -type d -name '.git'
The manual page of that utility will help you to tailor the use of the tool to your needs.
Did anyone succeed in setting up automated UIAutomation tests in Xcode?
I'm trying to set up a target in my Xcode project that should run all the UIAutomation scripts I prepared. Currently, the only Build Phase of this target is this Run Script block:
TEMPLATE="/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate"
MY_APP="/Users/Me/Library/Application Support/iPhone Simulator/6.0/Applications/564ED15A-A435-422B-82C4-5AE7DBBC27DD/MyApp.app"
RESULTS="/Users/Me/Projects/MyApp/Tests/UI/Traces/Automation.trace"
SCRIPT="/Users/Me/Projects/MyApp/Tests/UI/SomeTest.js"
instruments -t $TEMPLATE $MY_APP -e UIASCRIPT $SCRIPT -e UIARESULTSPATH $RESULTS
When I build this target it succeeds after a few seconds, but the script didn't actually run. In the build log I get these errors:
instruments[7222:707] Failed to load Mobile Device Locator plugin
instruments[7222:707] Failed to load Simulator Local Device Locator plugin
instruments[7222:707] Automation Instrument ran into an exception while trying to run the script. UIATargetHasGoneAWOLException
+0000 Fail: An error occurred while trying to run the script.
Instruments Trace Complete (Duration : 1.077379s; Output : /Users/Me/Projects/MyApp/Tests/UI/Traces/Automation.trace)
I am pretty sure, that my javascript and my run script are both correct, because if I run the exact same instruments command in bash it works as expected.
Could this be a bug in Xcode?
I finally found a solution for this problem. It seems like Xcode is running the Run Scripts with limited rights. I'm not entirely sure, what causes the instruments command to fail, but using su to change to your user will fix it.
su $USER -l -c <instruments command>
Obviously, this will ask you for your password, but you can't enter it when running as a script. I didn't find a way to specify the password for su, however if you run it as root, you don't have to specify one. Luckily sudo can accept a password via the pipe:
echo <password> | sudo -S su $USER -l -c <instruments command>
If you don't want to hardcode your password (always a bad idea), you could use some AppleScript to ask for the password.
I posted the resulting script below. Copy that to a *.sh file in your project and run that script from a Run Script.
#!/bin/bash
# This script should run all (currently only one) tests, independently from
# where it is called from (terminal, or Xcode Run Script).
# REQUIREMENTS: This script has to be located in the same folder as all the
# UIAutomation tests. Additionally, a *.tracetemplate file has to be present
# in the same folder. This can be created with Instruments (Save as template...)
# The following variables have to be configured:
EXECUTABLE="TestApp.app"
# Optional. If not set, you will be prompted for the password.
#PASSWORD="password"
# Find the test folder (this script has to be located in the same folder).
ROOT="$( cd -P "$( dirname "${BASH_SOURCE[0]}" )" && pwd )"
# Prepare all the required args for instruments.
TEMPLATE=`find $ROOT -name '*.tracetemplate'`
EXECUTABLE=`find ~/Library/Application\ Support/iPhone\ Simulator | grep "${EXECUTABLE}$"`
SCRIPTS=`find $ROOT -name '*.js'`
# Prepare traces folder
TRACES="${ROOT}/Traces/`date +%Y-%m-%d_%H-%M-%S`"
mkdir -p "$TRACES"
# Get the name of the user we should use to run Instruments.
# Currently this is done, by getting the owner of the folder containing this script.
USERNAME=`ls -l "${ROOT}/.." | grep \`basename "$ROOT"\` | awk '{print $3}'`
# Bring simulator window to front. Depending on the localization, the name is different.
osascript -e 'try
tell application "iOS Simulator" to activate
on error
tell application "iOS-Simulator" to activate
end try'
# Prepare an Apple Script that promts for the password.
PASS_SCRIPT="tell application \"System Events\"
activate
display dialog \"Password for user $USER:\" default answer \"\" with hidden answer
text returned of the result
end tell"
# If the password is not set directly in this script, show the password prompt window.
if [ -z "$PASSWORD" ]; then
PASSWORD=`osascript -e "$PASS_SCRIPT"`
fi
# Run all the tests.
for SCRIPT in $SCRIPTS; do
echo -e "\nRunning test script $SCRIPT"
COMMAND="instruments -t \"$TEMPLATE\" \"$EXECUTABLE\" -e UIASCRIPT \"$SCRIPT\""
COMMAND="echo '$PASSWORD' | sudo -S su $USER -l -c '$COMMAND'"
echo "$COMMAND"
eval $COMMAND > results.log
SCRIPTNAME=`basename "$SCRIPT"`
TRACENAME=`echo "$SCRIPTNAME" | sed 's_\.js$_.trace_g'`
mv *.trace "${TRACES}/${TRACENAME}"
if [ `grep " Fail: " results.log | wc -l` -gt 0 ]; then
echo "Test ${SCRIPTNAME} failed. See trace for details."
open "${TRACES}/${TRACENAME}"
exit 1
break
fi
done
rm results.log
It seems as though this really might be an Xcode problem; at any rate, at least one person has filed a Radar report on it. Someone in this other thread claims you can work around this exception by disconnecting any iDevices that are currently connected to the computer, but I suspect that does not apply when you're trying to run the script as an Xcode target.
I would suggest filing a Radar report as well; you may get further details on the issue from Apple, or at least convince them that many people are having the problem and they ought to figure out what's going on.
Sorry for a not-terribly-helpful answer (should have been a comment, but comments and links/formatting do not mix very well). Please update this question with anything you find out on the issue.
Note: this is not a direct answer to the question, but it is an alternative solution to the underlying problem.
While searching for in-depth information about UIAutomation, I stumbled across a framework by Square called KIF (Keep it functional). It is a integration testing framework that allows for many of the same features as UIAutomation, but the great thing about is is that you can just write your integration tests in Objective-C.
It is very easy to setup (via CocoaPods), they have good examples too, and the best thing is that it's a breeze to set up with your CI system like Jenkins.
Have a look at: http://github.com/square/KIF
Late to the game but I have a solution that works for Xcode 5.1. Don't know if that's what broke the above solution or not. With the old solution I was still getting:
Failed to load Mobile Device Locator plugin, etc.
However, this works for the release version of Xcode 5.1.
echo <password> | sudo -S -u username xcrun instruments
Notice I removed the unneeded su command and added the xcrun command. The xcrun was the magic that was needed.
Here is my complete command:
echo <password> | sudo -S -u username xcrun instruments\
-w "iPhone Retina (3.5-inch) - Simulator - iOS 7.1"\
-D "${PROJECT_DIR}/TestResults/Traces/Traces.trace"\
-t "${DEVELOPER_DIR}/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate"\
"${BUILT_PRODUCTS_DIR}/MyApp.app"\
-e UIARESULTSPATH "${PROJECT_DIR}/TestResults"\
-e UIASCRIPT "${PROJECT_DIR}/UITests/main.js"
By the way if you type:
instruments -s devices
you will get a list of all the supported devices you can use for the -w option.
Edit: To make this work for different people checking out the project replace the following:
echo <password> | sudo -S -u username xcrun instruments
with
sudo -u ${USER} xcrun instruments
Since you are just doing an sudo to the same user no password is required.
Take a look at this tutorial that explains how to have Automated UI testing with Jenkins. It also uses Jasmine in the tutorial though. http://shaune.com.au/automated-ui-testing-for-ios-apps-uiautomation-jasmine-jenkins/ hope this helps. It has an example project file so you can download that as a template. Hope this helps.
In XCode - if you load up organizer (XCode->Window->Organizer)
Then select your machine under devices -> 'Enable Developer Mode'
This should remove the need for prompts with instruments.
On Mac OS X, if I send SIGQUIT to my C program, it terminates, but there is no core dump file.
Do you have to manually enable core dumps on Mac OS X (how?), or are they written to somewhere else instead of the working directory?
It seems they are suppressed by default. Running
$ ulimit -c unlimited
Will enable core dumps for the current terminal, and it will be placed in /cores as core.PID. When you open a new session, it will be set to the default value again.
On macOS, your crash dumps are automatically handled by Crash Reporter.
You can find backtrace files by executing Console and going to User Diagnostic Reports section (under 'Diagnostic and Usage Information' group) or you can locate them in ~/Library/Logs/DiagnosticReports.
You can also check where dumps are generated by monitoring system.log file, e.g.
tail -f /var/log/system.log | grep crash
The actual core dump files you can find in /cores.
See also:
How to generate core dumps in Mac OS X?
Technical Note TN2118: Kernel Core Dumps.
Additionally, the /cores directory must exist and the user running the program must have write permissions on it.
The answer above,
ulimit -c unlimited
works -- but be sure to run that in the same terminal from which you will run the program that dumps core. You need to run the ulimit command first.
by default, specific directories in mac osx are hidden. you might want to enable this feature in the terminal and then the core dump should be visible within the directory /cores.
defaults write com.apple.finder AppleShowAllFiles TRUE
There is a great explanation by Quinn “The Eskimo!” on Apple's forums
https://developer.apple.com/forums/thread/694233
I roughly followed that guide. Here are the steps that I did.
Grant write all access to the /cores dir
PROMPT> ls -la / | grep cores
drwxr-xr-x 2 root wheel 64 Dec 8 2021 cores
PROMPT> sudo chmod 1777 /cores
PROMPT> ls -la / | grep cores
drwxrwxrwt 2 root wheel 64 Dec 21 23:29 cores
Set size of core file
PROMPT> ulimit -c unlimited
Compile and sign the program
PROMPT> cargo build --release -p my-crashing-program
PROMPT> /usr/libexec/PlistBuddy -c "Add :com.apple.security.get-task-allow bool true" tmp.entitlements
PROMPT> codesign -s - -f --entitlements tmp.entitlements my-crashing-program
Run the program
PROMPT> my-crashing-program
thread 'main' panicked at 'boom', my-crashing-program/src/main.rs:74:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
dumping core for pid 80995
zsh: quit my-crashing-program
Now there is a core file
PROMPT> ls /cores
core.80995
Also Apple's Console app has a list with Crash Reports.
It looks that OS X (10.6) does not generates codedumps by default.
Using the ulimit -c unlimited is not a good solution because ulimit does set the limit in an environment variable. This will work only for console applications executed from the shell that executed ulimit. If you have a gui application this will not work.
You can enable core dumps and then launch your GUI app from the command line using open.
$ ulimit -c unlimited
$ open /Applications/Address\ Book.app
I just looked at TN2124 and it suggests a similar approach, only without using open and just launching the app directly, e.g.
$ ulimit -c unlimited
$ /Applications/TextEdit.app/Contents/MacOS/TextEdit