CoreDumpDirectory isn't working on ubuntu; getting segmentation fault with php

Question

I'm trying to solve a segmentation fault. This message appears in my apache-error.log:

[notice] child pid 3979 exit signal Segmentation fault (11)

I've tried disabling some apache and php modules but I'm still getting the same error.

I've also tried putting this in apache2.conf:

CoreDumpDirectory /tmp/apache2-gdb-dump

and then chmod 777, chown www-data... so that the server can write.

I can see no core-dump files to give me a hint on the error.

Does anybody have an idea why CoreDumpDirectory isn't working on Ubuntu?

answers: $ ulimit -a core file size
(blocks, -c) unlimited data seg size
(kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 15863 max locked memory
(kbytes, -l) 32 max memory size
(kbytes, -m) unlimited open files
(-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues
(bytes, -q) 819200 real-time priority (-r) 0 stack size
(kbytes, -s) 8192 cpu time
(seconds, -t) unlimited max user processes (-u) 15863 virtual memory (kbytes, -v) unlimited file locks
(-x) unlimited

Solution 1

I finally was able to see Apache's core dump in Ubuntu:

1. edit /etc/default/apport

2. edit apache2.conf:

     CoreDumpDirectory /tmp/apache2-gdb-dump
   

3. make sure Apache can write to it:

   # chmod 777 /tmp/apache2-gdb-dump
   

4. remove core dump size limit:

   # ulimit -c unlimited
   

5. Optionally, change the name pattern of the core dumps:

   # echo 'coredump-%e.%p' > /proc/sys/kernel/core_pattern
   

To analyse the dump use gdb:

$ gdb apache2 /tmp/apache2-gdb-dump/coredump-x.x

To see stacktrace details, in gdb:

gdb> where

This I did, and I obtained the core-dump. However, my problem was not solved by looking at the coredump; it was apparently an issue in my php script.

More info: http://matrafox.info/apache-child-pid-exit-signal-segmentation-fault.html

Solution 2

Core dumps are disabled on Ubuntu by default

Try this:

ulimit -c unlimited

"ulimit -a" tells you what the current limit is (0 means disabled)

Solution 3

Do note that the subdirectory in /tmp will be removed after reboot, causing apache to not start due to configuration errors.

On a second note, the chowning is unnecessary. /tmp is chmodded 777 so anyone can read/write there.

@arod sudo ulimit -c does not work because -c is also an argument of sudo. You need to sudo -s, then ulimit -c