Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

I have a problem where a Python process is hitting a segmentation fault but not producing a core file.

The following is a toy example that does not produce a core file on the following distros:

  • Ubuntu 12.10
  • Fedora 18

but does produce core files on the following distros:

  • Scientific Linux 6
  • Mac OS X

$ python -c 'import time; time.sleep(120)'&
$ kill -abrt $! [1]+
Aborted python -c 'import time; time.sleep(120)'
$ ls core* ls: cannot access core*: No such file or directory

However, if I send a similar signal to a sleep instance I do get a core file:

$ sleep 120 &
$ kill -abrt $!
[1]+ Aborted (core dumped) sleep 120
$ ls core*
core.8603

On my Fedora 18 box, here is my /proc/sys/kernel/core_pattern:

$ cat /proc/sys/kernel/core_pattern
core

And I've set the following:

$ ulimit -c
unlimited

This is reproducible regardless of whether the abrtd service is running or not.

I'm pretty sure I've missed some basic configuration, but I don't know what. Thanks!

EDIT: This may be solvable by running:

$ echo 1 >/proc/sys/fs/suid_dumpable

share|improve this question
    
Is core a program on your system? What have you tried? Which of these has not solved your problem? wiki.ubuntu.com/Apport , ubuntuforums.org/archive/index.php/t-497562.html , stackoverflow.com/questions/5833218/… –  Ярослав Рахматуллин Jul 20 '13 at 8:06
    
Did you try setting suid_dumpable to 1? (only root can do that) –  pabouk Jul 23 '13 at 20:17
    
Please try following: ls -lL $(which python) ; python -c 'import time; time.sleep(5)' & grep core /proc/$!/limits ; ls -ld "$(readlink /proc/$!/cwd)" ; grep ^Sig /proc/$!/status ; kill $! The sequence will 1. list the Python binary to check if it is not suid; 2. list actual core limit of the process to check if it did not change; 3. list the working directory of the process to check if it is writeable by the user; 4. list signal masks of the process - please check if the SIGABRT (6) showing as 0000000000000020 is not blocked SigBlk, ignored SigIgn or caught SigCgt. –  pabouk Jul 23 '13 at 20:26

1 Answer 1

up vote 0 down vote accepted

tl;dr

$ echo 1 >/proc/sys/fs/suid_dumpable

(or the equivalent in /etc/sysctl.conf to persist the change across reboots)

longer

In my scenario I was using setcap to set certain capabilities on my Python process, to e.g. allow the use of raw sockets without having to be root. With this enabled you need to be root to get a core dump, or use the above command to explicitly tell the kernel it's OK for non-root users to get core dumps that they themselves can access.

(setting 2 would still enable core dumps in this situation but the said core dumps would only be accessible by the root user).

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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