5

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
unlimited

[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 <==
core

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

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

[dlee@dlee-oak t]$ tail /var/log/kern.log
<snip/>
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)
Gilles 'SO- stop being evil'
  • 807,993
  • 194
  • 1,674
  • 2,175
leedm777
  • 160
  • 7
  • 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 'SO- stop being evil' 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 'SO- stop being evil' Dec 21 '10 at 23:53
  • The Truth is at http://lxr.linux.no/linux+v2.6.36/fs/exec.c#L1963 , if anyone care to interpret it… – Gilles 'SO- stop being evil' Dec 21 '10 at 23:55
  • Gilles: An existing core file is not truncated. – leedm777 Dec 22 '10 at 06:37
  • From my reading of the [source](http://lxr.linux.no/linux+v2.6.36/fs/exec.c#L1963), 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 'SO- stop being evil' Dec 22 '10 at 20:09

1 Answers1

1

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.

leedm777
  • 160
  • 7