43

It seems like I can not generate core dumps in Mac OS X 10.6.8.

$ ulimit -c unlimited
$ ./a.out 
Hello world!
Segmentation fault
$ find ~/ -type f -name core 

# ls -la /cores/
total 0
drwxrwxr-t@  2 root  admin    68 24 jui  2010 .
drwxrwxr-t  31 root  admin  1122 17 oct 15:52 ..

My current directory, my HOME and /cores/ remain empty…

kenorb
  • 155,785
  • 88
  • 678
  • 743
alexpirine
  • 3,023
  • 1
  • 26
  • 41
  • possible duplicate of [Where are core dumps written](http://stackoverflow.com/questions/2080918/where-are-core-dumps-written-to-in-mac-os-x). /core/ may contain files hidden, hence set `defaults write com.apple.finder AppleShowAllFiles TRUE ` – Bort Feb 23 '12 at 16:17
  • Thanks for your answer Bort, but I've already seen this thread ; it's not about hidden files. – alexpirine Feb 23 '12 at 19:56
  • 2
    Apple saves core files in the `/cores` directory. Ensure the permissions on the directory are set properly. See Apple's [Mac OS X Debugging Magic](https://developer.apple.com/library/mac/technotes/tn2124/_index.html). Also, don't you need a leading dot "." so the changes are applied to the current shell and all child shells? – jww Nov 28 '13 at 06:41
  • 3
    Or you can just enable core dumps in your terminal without the restart: http://mindarray.org/techlog/gdb-debugging.html – David Mertens May 15 '14 at 19:12
  • And if you want to not have to use /cores you could always make a symlink in your home directory (or wherever you wish) to point to /cores though this would only add a way to reference the file. – Pryftan Jun 29 '19 at 15:25
  • 2
    Archive of: [mindarray.org/techlog/gdb-debugging.html](https://web.archive.org/web/20120113040608/http://www.mindarray.org/techlog/gdb-debugging.html) – M.W. Mar 25 '20 at 20:45

4 Answers4

61

By default, crashes are reported into .crash files which can be found in /Library/Logs/DiagnosticReports (system-wide) and ~/Library/Logs/DiagnosticReports (user). These files can be opened by using Console app, in User or System Reports. The .crash files are in plain text format and should include relevant information about the crash.

In order to activate the full core dumps, make sure that /cores directory has write permissions for the current user (test by: touch /cores/test && rm /cores/test). In addition, make sure that you don't have any limits on core file sizes by:

ulimit -c unlimited

The name of the core dump file is in format: core.PID.

If the directory is hidden, you can show the hidden files by:

defaults write com.apple.finder AppleShowAllFiles TRUE

You can test that by the following commands:

sleep 100 &
killall -SIGSEGV sleep

which should say extra (core dumped), after Segmentation fault message.

The core dump files should be found by default in /cores directory.

Example by commands:

$ ulimit -c unlimited
$ sleep 100 &
$ killall -SIGSEGV sleep # Then press Enter few times till below message is shown
[1]+  Segmentation fault: 11  (core dumped) sleep 100
$ ls /cores
core.13652
$ lldb -c /cores/core.*
(lldb) target create --core "/cores/core.13652"
Core file '/cores/core.13652' (x86_64) was loaded.
(lldb) bt
* thread #1, stop reason = signal SIGSTOP
  * frame #0: 0x00007fffa7d13fde libsystem_kernel.dylib`__semwait_signal + 10
    frame #1: 0x00007fffa7c9ab92 libsystem_c.dylib`nanosleep + 199
    frame #2: 0x000000010c090002 sleep`rpl_nanosleep + 128

See also: Technical Note TN2118 - Kernel Core Dumps.

kenorb
  • 155,785
  • 88
  • 678
  • 743
  • 1
    This is true, but not as useful as a true core dump; if you need more information on _why_ the application crashed (and the context surrounding the crash), there's just no substitute for a core dump if you can't replicate the crash scenario on your machine for any reason. – fraveydank May 18 '14 at 19:44
  • @fraveydank I've simplified the answer to avoid confusion. The OS X have its own format of core dumps and they've a proper context. These core dump files can be found in `/cores`. – kenorb Oct 06 '16 at 12:41
  • 12
    These core dump instructions no longer seem to work on macOS 10.13. I did the `ulimit` thing and verified that `/cores` is writable, but no core appears in `/cores`, and no "(core dumped)" message appears with the "Segmentation fault" message (https://gist.github.com/apjanke/756bdae743e6a220b49d910bd4baf4f0) Any ideas how to enable this for newer versions of macOS? – Andrew Janke Jan 21 '19 at 00:05
  • 2
    This answer worked for me on 10.14 just now and produced a cores file `/cores/core.19098` for a SIGSEGV. – user3093235 Sep 06 '19 at 10:00
  • Launch the process to be dumped from the same terminal where `ulimit -c unlimited` has been set. E.g. to core dump TextEdit, launch it from the command line using the full path `/Applications/TextEdit.app/Contents/MacOS/TextEdit` – M.W. Mar 25 '20 at 20:48
  • Not working on 10.15.4 (using `ulimit -c unlimited` and the `sleep` test shown above). /cores directory is world writeable, but I'm not an admin on this machine; don't know if that's related or not. – Joe Strout Apr 14 '20 at 16:23
  • ...and just to follow up: now trying again with an admin account, it still doesn't work. – Joe Strout Apr 14 '20 at 16:55
  • does not not work for me in 2021 with macos BigSur – kyb Mar 15 '21 at 18:15
  • 2
    2021 works if you also sudo chown (whoami) /cores or sudo chown $(whoami) /cores – StefanS Jul 14 '21 at 10:42
  • For anyone else stumbling into here, it seems /bin commands cannot generate core dumps, so the kill sleep command doesn't work to validate. This is per https://stackoverflow.com/a/60396365/410074 – Chris Aug 10 '21 at 02:32
13

You can generate core dump files on Mac Os X like this:

  1. Create the file : /etc/launchd.conf, then :

    echo "limit core unlimited" | sudo tee -a /etc/launchd.conf

  2. Restart your Mac.

And that's it, the core dump files are generated in the /cores directory. Be careful the core dump files are large files so when you finishing troubleshooting your code, remove them.

Community
  • 1
  • 1
TOC
  • 4,326
  • 18
  • 21
  • 3
    I did it and nothing happened differently. Is the system supposed to pick that up? Do I need to enable core dump in the JVM settings? – Developer Dec 09 '15 at 00:28
  • 3
    Is there any way to generate the core dump file at the directory of crashed program by default? – Fermat's Little Student Dec 11 '15 at 02:04
  • 2
    This solution also did not work for me. I followed the instructions precisely and double checked my file name and the contents of launchd.conf. – Jason Jun 12 '18 at 14:32
  • @Developer I believe there has been some sort of change in more recent versions of macOS. I tried this with another limit and it didn't seem to work. Or so I think it was a limit. Certainly I did use that file and didn't have success so maybe it had already changed in 2015. – Pryftan Jun 29 '19 at 15:27
  • @Jason See my comment to Developer on why this might be (though I cannot confirm that it's why I somehow suspect it's relevant). – Pryftan Jun 29 '19 at 15:27
12

Apple list a number of ways to generate core dump files in their TN2124 or Mac OS X Debugging Magic.

Here's a couple of extracts:

Prior to Mac OS X 10.4, you would enable core dumps on a system-wide basis by changing the line "COREDUMPS=-NO-" in /etc/hostconfig to "COREDUMPS=-YES-" and then restarting

And 

# BSH
$ ulimit -c unlimited

# CSH
% limit coredumpsize unlimited

You can even do it programatically:

#include <sys/resource.h>

static bool EnableCoreDumps(void)
{
    struct rlimit   limit;

    limit.rlim_cur = RLIM_INFINITY;
    limit.rlim_max = RLIM_INFINITY;
    return setrlimit(RLIMIT_CORE, &limit) == 0;
}
jww
  • 97,681
  • 90
  • 411
  • 885
  • In `/etc/hostconfig` file the comment says: `This file is going away`, so this file would be depreciated soon. The type of preferences previously found in `hostconfig` is now contained within the launchd .plist files themselves. For example, when you turn off AFP sharing in System Preferences, it's added to the `com.apple.AppleFileServer.plist` in `/System/Library/LaunchDaemons` – kenorb Oct 11 '14 at 14:21
  • I’m tempted to down vote this simply for referencing the ghastly csh... Okay not really. But that's a good point of explaining (and so csh or no I’ve up voted it) *`setrlimit()`* for those who don't know about it (I do but I suspect many do not - although I've always had `ulimit -c unlimited` enabled so never needed it for core dumps). – Pryftan Jun 29 '19 at 15:22
6

On the Mac OS X Yosemite, you can enable the core dump on a per-process basis using LLDB. Assuming your process id is 51918, run the following from bash:

$ lldb
(lldb) attach 51918
Process 51918 stopped
* thread #1: tid = 0x6bf50, 0x00007fff927c14de libsystem_kernel.dylib`mach_msg_trap + 10, queue = 'com.apple.main-thread', stop reason = signal SIGSTOP
    frame #0: 0x00007fff927c14de libsystem_kernel.dylib`mach_msg_trap + 10
libsystem_kernel.dylib`mach_msg_trap:
->  0x7fff927c14de <+10>: retq   
    0x7fff927c14df <+11>: nop    

libsystem_kernel.dylib`mach_msg_overwrite_trap:
    0x7fff927c14e0 <+0>:  movq   %rcx, %r10
    0x7fff927c14e3 <+3>:  movl   $0x1000020, %eax

Executable module set to "/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/bin/java".
Architecture set to: x86_64h-apple-macosx.

(lldb) expr long long * $limit = (long long *)malloc(16)
(lldb) expr $limit[0] = 0x7fffffffffffffff
(long long) $0 = 9223372036854775807
(lldb) expr $limit[1] = 0x7fffffffffffffff
(long long) $1 = 9223372036854775807
(lldb) expr (int)setrlimit(4, $limit)
(int) $2 = 0
(lldb) detach
Process 51918 detached

If you process causes a segmentation fault, you will now find a core in /cores. You can check this be sending a SIGABRT to your process after running the above:

kill -ABRT 51918

Please note that attaching to process owned by root won't work on recent macOSes (El Capitan and above) by default due to System Integrity Protection.

kenorb
  • 155,785
  • 88
  • 678
  • 743
adamretter
  • 3,885
  • 2
  • 23
  • 43