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
Related
While running make check for mesos-1.9.0 on mac os, I get an error for 'ulimit -u`. This is the error message on Terminal
Detected low process count ulimit (2837 vs 4096). Increase 'ulimit -u' to avoid spurious test failures.
I tried setting the hard and soft limits for ulimit (ulimit -u 4096and ulimit -n 4096) on the Terminal as well as updating my .bash_profile and running source ~/.bash_profile but make check still fails.
Can someone help me fix this ?
TIA.
sudo ulimit -n 65536 200000
Reference: https://wilsonmar.github.io/maximum-limits
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.
*/
I don't know if I'm doing something wrong but when I type
$limit stacksize unlimited
Into a terminal on Mountain Lion I get:
-bash: limit: command not found
and so I try:
sudo ulimit -s unlimited
Which won't work either. Can you please tell me what I should be using to get an unlimited stacksize in terminal?
I have now realised that for the limit command I need to use a tcsh shell.
I need to lean on you for some help on stracing android apps in the sdk emulator
here is my setup
android sdk emulator running android api 4.03
adb shell connected to emulator.
I am able to install an apk usng adb install filename.apk
I am able to run the app using
adb shell
am start -a android.intent.action.Main -n com.akproduction.notepad/com.akproduction.notepad.NoteList
I try to strace using (adb shell)
strace am start -a android.intent.action.Main -n com.akproduction.notepad/com.akproduction.notepad.NoteList
but I get nothing!
how do you trace the runtime behavior of android apps and their installation ?
thanks,
Jose.
p.s. the test app is located here: http://www.appbrain.com/app/ak-notepad/com.akproduction.notepad
am is a batch file and cannot be used in strace.
You need to run it like this:
strace -v -fF -tt -s 65535 -o /data/local/tmp/opengl.strace /system/bin/app_process /system/bin com.android.commands.am.Am start -a android.intent.action.MAIN -n demo.opengl.android/.OpenGLDemo
BTW don't use the strace statically compiled binary available for download from:
http://benno.id.au/blog/2007/11/18/android-runtime-strace
It will output nothing.
Instead use the one which comes with the ROM.
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.