Why core dump file is generated ?

Question

I am working on a Linux project for which I've written a makefile. Sometimes when I run my code a core dump file is generated. The filename is of the form core.* . And it is occupying too much space.

Now, how to avoid this core dump file from being generated? Also can anyone tell why it is generated only sometimes?

One more thing. Is there any use from the core dumped file? Also in my program "Segmentation fault" is not happening but still it is generated. So what kind of fault may be there?

The core dump file is generated when the program is terminated by Ctrl+\ is given by me. The program is not terminating abruptly.

Why a core dump file is generated when Ctrl+\ is pressed. I tried Ctrl+C , Ctrl+Z , then it is not generated. Can anyone tell why it is generated only when Ctrl+\ is pressed. I believe it is SIGQUIT and not SIGABRT or SIGSEGV.

Answer 1

A process dumps core when it is terminated by the operating system due to a fault in the program. The most typical reason this occurs is because the program accessed an invalid pointer value. Given that you have a sporadic dump, it's likely that you are using an uninitialized pointer.

Can you post the code that is causing the fault? Other than vague generalizations it's hard to guess what's wrong without actually seeing code.

As for what a core dump actually is, check out this Wikipedia article:

• http://en.wikipedia.org/wiki/Core_dump

Answer 2

It's a tool to aid in debugging an application that's behaving badly. It's large because it contains the contents of all the applications physical memory at the time it died as well as the register states and stacks of all its threads.

They get generated when the kernel kills an application for doing something evil, like generating a segmentation violation or a bus error.

Answer 3

Core dumps are generated when the process receives certain signals, such as SIGSEGV, which the kernels sends it when it accesses memory outside its address space. Typically that happens because of errors in how pointers are used. That means there's a bug in the program.

The core dump is useful for finding the bug. It is an image of the the process's memory at the time of the problem, so a debugger such as gdb can be used to see what the program was doing then. The debugger can even access (sometimes) the values of variables in the program.

You can prevent core dumps from happening using the ulimit command.

Answer 4

As said by others before the core dump is the result of a fault in the program.

You can configure if a core dump is to be generated with the ulimit command. Entering

ulimit -c 0

disables core file generation in the active shell.

If the program that generated the core was built with symbol information you can do a post mortem debugging session like this:

gdb <pathto/executable> --core <corefilename>

Answer 5

You can avoid creating a core dump file by writing code that doesn't crash :)

Seriously, core dumps are useful because you can see the state of the program when it crashed, for "post mortem" debugging. You can open them in gdb and inspect the state of your program (especially if it was built with debugging).

Core dumps usually get made if the program has a SIGSEGV (usually caused by invalid pointer dereferencing), SIGABRT (which would happen if you called abort(), or in C++ by the default terminate() handler for exceptions in destructors etc) or some other fault. You can also trigger them explicitly with the debugger or programmatically.

If you've fixed all the bugs and it's perfect, you can delete them. Also, if you've changed your program in any way (and recompiled it) then they will become useless as the debug info now won't match what's in the core dump, so you can delete them then too.

Answer 6

ctrl + \ sends signal SIGQUIT to the process. According to POSIX.1 standard, the default action for this signal is to generate a core.

SIGILL, SIGABRT, SIGFPE, SIGSEGV are other cases when system will generate a core.

Please refer "man 7 signal" on your system for more details.

Thanks, Onkar