How to generate a core dump in Linux on a segmentation fault

Question

I have a process in Linux that s getting a segmentation fault   How can I tell it to generate a core dump when it fails

User · Accepted Answer

This depends on what shell you are using. If you are using bash, then the ulimit command controls several settings relating to program execution, such as whether you should dump core. If you type

ulimit -c unlimited

then that will tell bash that its programs can dump cores of any size. You can specify a size such as 52M instead of unlimited if you want, but in practice this shouldn't be necessary since the size of core files will probably never be an issue for you.

In tcsh, you'd type

limit coredumpsize unlimited

User · Answer

In order to activate the core dump do the following    In   etc profile comment the line     ulimit -S -c 0  gt   dev null 2 gt  amp 1  In  etc security limits conf comment out the line                   soft    core            0  execute the cmd limit coredumpsize unlimited and check it with cmd limit     limit coredumpsize unlimited   limit cputime      unlimited filesize     unlimited datasize     unlimited stacksize    10240 kbytes coredumpsize unlimited memoryuse    unlimited vmemoryuse   unlimited descriptors  1024 memorylocked 32 kbytes maxproc      528383    to check if the corefile gets written you can kill the relating process with cmd kill -s SEGV  lt PID gt   should not be needed  just in case no core file gets written this can be used as a check      kill -s SEGV  lt PID gt     Once the corefile has been written make sure to deactivate the coredump settings again in the relating files  1  2  3

User · Answer

For Ubuntu 14 04   Check  core dump enabled   ulimit -a  One of the lines should be     core file size           blocks  -c  unlimited  If not    gedit    bashrc and add ulimit -c unlimited to end of file and save  re-run terminal  Build your application with debug information    In Makefile -O0  -g Run application that create core dump  core dump file with name    core    should be created near application name file      application name  Run under gdb   gdb application name core

User · Answer

By default you will get a core file    Check to see that the current directory of the process is writable  or no core file will be created

User · Answer

To check where the core dumps are generated  run   sysctl kernel core pattern   or   cat  proc sys kernel core pattern   where  e is the process name and  t the system time  You can change it in  etc sysctl conf and reloading by sysctl -p   If the core files are not generated  test it by  sleep 10  amp  and killall -SIGSEGV sleep   check the limits by  ulimit -a   If your core file size is limited  run   ulimit -c unlimited   to make it unlimited   Then test again  if the core dumping is successful  you will see     core dumped     after the segmentation fault indication as below      Segmentation fault  11   core dumped    See also  core dumped - but core file is not in current directory     Ubuntu  In Ubuntu the core dumps are handled by Apport and can be located in  var crash   However  it is disabled by default in stable releases   For more details  please check  Where do I find the core dump in Ubuntu    macOS  For macOS  see  How to generate core dumps in Mac OS X

User · Answer

Maybe you could do it this way  this program is a demonstration of how to trap a segmentation fault and shells out to a debugger  this is the original code used under AIX  and prints the stack trace up to the point of a segmentation fault  You will need to change the sprintf variable to use gdb in the case of Linux    include  lt stdio h gt   include  lt signal h gt   include  lt stdlib h gt   include  lt stdarg h gt   static void signal handler int   static void dumpstack void   static void cleanup void   void init signals void   void panic const char           struct sigaction sigact  char  progname   int main int argc  char   argv        char  s      progname     argv       atexit cleanup       init signals        printf  About to seg fault by assigning zero to  s n         s   0      sigemptyset  amp sigact sa mask       return 0     void init signals void        sigact sa handler   signal handler      sigemptyset  amp sigact sa mask       sigact sa flags   0      sigaction SIGINT   amp sigact   struct sigaction   NULL        sigaddset  amp sigact sa mask  SIGSEGV       sigaction SIGSEGV   amp sigact   struct sigaction   NULL        sigaddset  amp sigact sa mask  SIGBUS       sigaction SIGBUS   amp sigact   struct sigaction   NULL        sigaddset  amp sigact sa mask  SIGQUIT       sigaction SIGQUIT   amp sigact   struct sigaction   NULL        sigaddset  amp sigact sa mask  SIGHUP       sigaction SIGHUP   amp sigact   struct sigaction   NULL        sigaddset  amp sigact sa mask  SIGKILL       sigaction SIGKILL   amp sigact   struct sigaction   NULL      static void signal handler int sig        if  sig    SIGHUP  panic  FATAL  Program hanged up n        if  sig    SIGSEGV    sig    SIGBUS           dumpstack            panic  FATAL   s Fault  Logged StackTrace n    sig    SIGSEGV     Segmentation      sig    SIGBUS     Bus     Unknown               if  sig    SIGQUIT  panic  QUIT signal ended program n        if  sig    SIGKILL  panic  KILL signal ended program n        if  sig    SIGINT       void panic const char  fmt             char buf 50       va list argptr      va start argptr  fmt       vsprintf buf  fmt  argptr       va end argptr       fprintf stderr  buf       exit -1      static void dumpstack void           Got this routine from http   www whitefang com unix faq toc html        Section 6 5  Modified to redirect to file to prevent clutter               This needs to be changed           char dbx 160        sprintf dbx   echo  where ndetach    dbx -a  d  gt   s dump   getpid    progname          Change the dbx to gdb         system dbx       return     void cleanup void        sigemptyset  amp sigact sa mask          Do any cleaning up chores here        You may have to additionally add a parameter to get gdb to dump the core as shown here in this blog here

User · Answer

It s worth mentioning that if you have a systemd set up  then things are a little bit different  The set up typically would have the core files be piped  by means of core pattern sysctl value  through systemd-coredump 8   The core file size rlimit would typically be configured as  unlimited  already   It is then possible to retrieve the core dumps using coredumpctl 1    The storage of core dumps  etc  is configured by coredump conf 5   There are examples of how to get the core files in the coredumpctl man page  but in short  it would look like this   Find the core file    vps phoenix    coredumpctl list test me   tail -1 Sun 2019-01-20 11 17 33 CET   16163  1224  1224  11 present  home vps test me   Get the core file    vps phoenix    coredumpctl -o test me core dump 16163

User · Answer

As explained above the real question being asked here is how to enable core dumps on a system where they are not enabled  That question is answered here   If you ve come here hoping to learn how to generate a core dump for a hung process  the answer is    gcore  lt pid gt    if gcore is not available on your system then    kill -ABRT  lt pid gt    Don t use kill -SEGV as that will often invoke a signal handler making it harder to diagnose the stuck process

User · Answer

Ubuntu 19 04  All other answers themselves didn t help me  But the following sum up did the job  Create    config apport settings with the following content    main  unpackaged true    This tells apport to also write core dumps for custom apps   check  ulimit -c  If it outputs 0  fix it with  ulimit -c unlimited   Just for in case restart apport       sudo systemctl restart apport   Crash files are now written in  var crash   But you cannot use them with gdb  To use them with gdb  use  apport-unpack  lt location of report gt   lt target directory gt    Further information    Some answers suggest changing core pattern  Be aware  that that file might get overwritten by the apport service on restarting  Simply stopping apport did not do the job The ulimit -c value might get changed automatically while you re trying other answers of the web  Be sure to check it regularly during setting up your core dump creation    References    https   stackoverflow com a 47481884 6702598

User · Answer

Better to turn on core dump programmatically using system call setrlimit   example    include  lt sys resource h gt   bool enable core dump            struct rlimit corelim       corelim rlim cur   RLIM INFINITY      corelim rlim max   RLIM INFINITY       return  0    setrlimit RLIMIT CORE   amp corelim

User · Answer

There are more things that may influence the generation of a core dump   I encountered these    the directory for the dump must be writable   By default this is the current directory of the process  but that may be changed by setting  proc sys kernel core pattern    in some conditions  the kernel value in  proc sys fs suid dumpable may prevent the core to be generated    There are more situations which may prevent the generation that are described in the man page - try man core

User · Answer

What I did at the end was attach gdb to the process before it crashed  and then when it got the segfault I executed the generate-core-file command   That forced generation of a core dump

[linux] How to generate a core dump in Linux on a segmentation fault?

Examples related to linux

Examples related to bash

Examples related to unix

Examples related to coredump

Examples related to tcsh