How to generate a core dump in Linux on a segmentation fault?
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?
13 Answers 13
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
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.
limit coredumpsize unlimited @lzprgmr: To clarify: the reason why core dumps are not generated by default is that the limit is not set and/or set to 0, which prevents the core from being dumped. By setting a limit of unlimited, we guarantee that core dumps can always be generated.
This link goes deeper and gives some more options to enable generation of core dumps in linux. The only drawback is that some commands/settings are left unexplained.
On bash 4.1.2(1)-release limits such as 52M cannot be specified, resulting in a invalid number error message. The man page tells that «Values are in 1024-byte increments».
Well I had a «small» OpenGL project, that once did some weird thing, and caused X-server crash. When I logged back, I saw a cute little 17 GB core file (on a 25 GB partition). It’s definitely a good idea to keep the core file’s size limited 🙂
@PolarisUser: If you wanted to make sure your partition doesn’t get eaten, I recommend setting a limit of something like 1 gig. That should be big enough to handle any reasonable core dump, while not threatening to use up all of your remaining hard drive space.
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
if gcore is not available on your system then
Don’t use kill -SEGV as that will often invoke a signal handler making it harder to diagnose the stuck process
I think it’s far more likely that -ABRT will invoke a signal handler than -SEGV , as an abort is more likely to be recoverable than a segfault. (If you handle a segfault, normally it’ll just trigger again as soon as your handler exits.) A better choice of signal for generating a core dump is -QUIT .
To check where the core dumps are generated, run:
sysctl kernel.core_pattern 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 & and killall -SIGSEGV sleep ), check the limits by: ulimit -a .
If your core file size is limited, run:
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)
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.
macOS
For Ubuntu, to quickly revert to normal behavior (dumping a core file in the current directory), simply stop the apport service with «sudo service apport stop». Also note that if you are running within docker, that setting is controlled on the host system and not within the container.
Instead of disabling apport every time it could be more lasting just to uninstall apport (ignoring the recommendation dependency) since the service adds no value for developers.
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.
To answer to Ritwik G, to attach a process to gdb, simply launch gdb and enter ‘attach
Weird thing is I already set ulimit -c to unlimited , but the core file is stilled no created, the generate-core-file file in gdb session does create the core file, thanks.
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 #include #include #include 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(&sigact.sa_mask); return 0; >void init_signals(void) < sigact.sa_handler = signal_handler; sigemptyset(&sigact.sa_mask); sigact.sa_flags = 0; sigaction(SIGINT, &sigact, (struct sigaction *)NULL); sigaddset(&sigact.sa_mask, SIGSEGV); sigaction(SIGSEGV, &sigact, (struct sigaction *)NULL); sigaddset(&sigact.sa_mask, SIGBUS); sigaction(SIGBUS, &sigact, (struct sigaction *)NULL); sigaddset(&sigact.sa_mask, SIGQUIT); sigaction(SIGQUIT, &sigact, (struct sigaction *)NULL); sigaddset(&sigact.sa_mask, SIGHUP); sigaction(SIGHUP, &sigact, (struct sigaction *)NULL); sigaddset(&sigact.sa_mask, SIGKILL); sigaction(SIGKILL, &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 >%s.dump", getpid(), progname); /* Change the dbx to gdb */ system(dbx); return; > void cleanup(void) < sigemptyset(&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.
Resolving Segmentation Fault (“Core dumped”) in Ubuntu
This error may strike your Ubuntu at any point at the moment. A few days ago when I was doing my routine work in my Ubuntu laptop, suddenly I encountered with an error “Segmentation fault ( core dumped)” then I got to know that, this error can strike you Ubuntu or any other operating system at any point of the moment as binaries crashing doesn’t depend on us.
Segmentation fault is when your system tries to access a page of memory that doesn’t exist. Core dumped means when a part of code tries to perform read and write operation on a read-only or free location. Segfaults are generally associated with the file named core and It generally happens during up-gradation.
While running some commands during the core-dump situation you may encounter with “Unable to open lock file” this is because the system is trying to capture a bit block which is not existing, This is due to the crashing of binaries of some specific programs.
You may do backtracking or debugging to resolve it but the solution is to repair the broken packages and we can do it by performing the below-mentioned steps:
Command-line:
Step 1: Remove the lock files present at different locations.
sudo rm -rf /var/lib/apt/lists/lock /var/cache/apt/archives/lock /var/lib/dpkg/lock and restart your system h.cdccdc Step 2: Remove repository cache.
Step 3: Update and upgrade your repository cache.
sudo apt-get update && sudo apt-get upgrade Step 4: Now upgrade your distribution, it will update your packages.
Step 5: Find the broken packages and delete them forcefully.
sudo dpkg -l | grep ^..r | apt-get purge Apart from the command line, the best way which will always work is:
Step 1: Run Ubuntu in startup mode by pressing the Esc key after the restart.
Step 2: Select Advanced options for Ubuntu
Step 3: Run Ubuntu in the recovery mode and you will be listed with many options.
Step 4: First select “Repair broken packages”
Step 5: Then select “Resume normal boot”
So, we have two methods of resolving segmentation fault: CLI and the GUI. Sometimes, it may also happen that the “apt” command is not working because of segfault, so our CLI method will not work, in that case also don’t worry as the GUI method gonna work for us always.