I have an application that I'm working on, and I'm having trouble getting a core dump when it segfaults. In fact, I'm having trouble getting real core dump files at all. A simple test case will generate a core dump file, but it's zero length.

I've got ulimit -c unlimited set. This is 64-bit Ubuntu Maverick. Any hint what to do next?

[dlee@dlee-oak t]$ ulimit -c

[dlee@dlee-oak t]$ cat mkcore.cpp
int main() { *((int *)0) = 0; }

[dlee@dlee-oak t]$ g++ -g mkcore.cpp -o mkcore

[dlee@dlee-oak t]$ ./mkcore 
Segmentation fault

[dlee@dlee-oak t]$ ls -l core*
-rw-r--r-- 1 dlee dlee 0 2010-12-21 15:00 core.2993

Edit: More information

[dlee@dlee-oak t]$ tail -n +1 /proc/sys/kernel/core_*
==> /proc/sys/kernel/core_pattern <==

==> /proc/sys/kernel/core_pipe_limit <==

==> /proc/sys/kernel/core_uses_pid <==

[dlee@dlee-oak t]$ tail /var/log/kern.log
Dec 21 16:07:40 dlee-oak kernel: [  133.863045] mkcore[1589]: segfault at 0 ip 000000000040043d sp 00007fffbd025510 error 6 in mkcore[400000+aa000]

I've just realized that the filesystem the core file is being generated on is a Parallels Shared Folder. (This Ubuntu instance is running on a Parallels VM on my Mac). When I run the app from a directory that's on local disk, core file is generated as expected.

So I'll change the question slightly: why isn't it generating the core file on the prl_fs filesystem? Just curious...

Edit #2:

You'll note that when it generates the zero length core file, it does not print (core dumped). I did double check my sanity, and yes the zero length core file is really being created.

[dlee@dlee-oak t]$ X=$(pwd)
[dlee@dlee-oak t]$ ls -l core*
ls: cannot access core*: No such file or directory
[dlee@dlee-oak t]$ ./mkcore 
Segmentation fault
[dlee@dlee-oak t]$ ls -l core*
-rw-r--r-- 1 dlee dlee 0 2010-12-22 00:41 core.6009

[dlee@dlee-oak t]$ cd ~
[dlee@dlee-oak ~]$ $X/mkcore
Segmentation fault (core dumped)
  • What's the output of tail -n +1 /proc/sys/kernel/core_* (shows various global kernel parameters related to core dumps)? Is there any related output in /var/log/kern.log? – Gilles Dec 21 '10 at 21:52
  • Ok, that's a highly specific issue. If you create the core file and put some contents in it, is it truncated? (Either set core_uses_pid to 0 or run sh -c 'echo foo >core.$$; exec ./mkcore'.) – Gilles Dec 21 '10 at 23:53
  • The Truth is at lxr.linux.no/linux+v2.6.36/fs/exec.c#L1963 , if anyone care to interpret it… – Gilles Dec 21 '10 at 23:55
  • Gilles: An existing core file is not truncated. – leedm777 Dec 22 '10 at 6:37
  • From my reading of the source, a core file that's created but not truncated could mean: the file has a link count ≥2 (no); some weird caching behavior such that d_unhashed is true (?); the file is not a regular file (no); the file is not owned by you (no); you can't write to the file (no). Is the source of the kernel part of the Parallels tools available? – Gilles Dec 22 '10 at 20:09

I couldn't clearly find the underlying reason why, but the zero length core file was caused by trying to create the core file on a Parallels Shared Folder.

I solved the problem by running the application from a local directory. I suppose another alternative would be to set /proc/sys/kernel/core_pattern to dump core files into a local directory.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.