macOS Slow core dumping under OS X

[Arathorn]

Hi all,

I do a fair bit of BSDish development under OS X in C and C++, and inevitably get my fair share of segfaults. With coredumping enabled (ulimit -c unlimited), I find the kernel takes ages to actually produce a core - about 13 seconds for a trivial one-liner null pointer dereference in C on my 2GHz MBP, on 10.6.1:

$ echo 'main() { *(int *)(0) = 1; }' | gcc -x c - && time ./a.out
Bus error (core dumped)

real 0m12.746s
user 0m0.001s
sys 0m0.377s
$ ls -alh /cores/core.16181
-r-------- 1 matthew admin 256M 3 Nov 02:08 /cores/core.16181

I'm sure this didn't use to take so long - it's really annoying to wait around for >30s for a non-trivial program to dump core whenever something goes wrong. How does it compare for other folks? Is there some secret I'm missing for speeding this up? For comparison under Linux on parallels on the same box...:

$ echo 'main() { *(int *)(0) = 1; }' | gcc -x c - && time ./a.out
Segmentation fault (core dumped)

real 0m0.020s
user 0m0.000s
sys 0m0.000s
$ ls -alh core
-rw------- 1 matthew users 52K 2009-11-03 02:13 core

:-/

 

[gnasher729]

Hi all,

I do a fair bit of BSDish development under OS X in C and C++, and inevitably get my fair share of segfaults. With coredumping enabled (ulimit -c unlimited), I find the kernel takes ages to actually produce a core - about 13 seconds for a trivial one-liner null pointer dereference in C on my 2GHz MBP, on 10.6.1:

$ echo 'main() { *(int *)(0) = 1; }' | gcc -x c - && time ./a.out
Bus error (core dumped)

real 0m12.746s
user 0m0.001s
sys 0m0.377s
$ ls -alh /cores/core.16181
-r-------- 1 matthew admin 256M 3 Nov 02:08 /cores/core.16181

I'm sure this didn't use to take so long - it's really annoying to wait around for >30s for a non-trivial program to dump core whenever something goes wrong. How does it compare for other folks? Is there some secret I'm missing for speeding this up? For comparison under Linux on parallels on the same box...:

$ echo 'main() { *(int *)(0) = 1; }' | gcc -x c - && time ./a.out
Segmentation fault (core dumped)

real 0m0.020s
user 0m0.000s
sys 0m0.000s
$ ls -alh core
-rw------- 1 matthew users 52K 2009-11-03 02:13 core

:-/

The answer to the "why" is staring right at you:

-r-------- 1 matthew admin 256M 3 Nov 02:08 /cores/core.16181
-rw------- 1 matthew users 52K 2009-11-03 02:13 core

I think MacOS X has some debugging tools that are preferable to core dumps.

 

[Arathorn]

The answer to the "why" is staring right at you:

-r-------- 1 matthew admin 256M 3 Nov 02:08 /cores/core.16181
-rw------- 1 matthew users 52K 2009-11-03 02:13 core

I think MacOS X has some debugging tools that are preferable to core dumps.

Yup, I had spotted the difference in core size - and indeed it takes 8 seconds to dump 256M of /dev/zero to disk on my MBP, so that's where the majority of the time is going. My question was more whether there were options to pare down the size of the core file. Or what the debugging tools actually are which are preferable to core dumps