What is segmentation fault in linux

What Is a Segmentation Fault in Linux?

To understand the concept of a segmentation fault in a Linux operating system environment, we have to first address the concept of segmentation. In operating systems; under process management, each process is associated with a distinct virtual address space, hence the concept of segmentation.

Supposing a memory location like 0x877 is evident on your Linux operating system. Also, suppose two processes (A and B) have access to read this memory location (0x877).

Process A reading memory location 0x877 will access targeted information at a different RAM location in comparison to Process B because Process B’s attempt to read memory location 0x877 (for targeted info) will also be at a unique RAM location.

Therefore, the issue of segmentation fault arises when a program’s access or access attempt to a memory location is either not allowed or not assigned by the Linux operating system.

This article guide seeks to break down the issue of a segmentation fault in a Linux operating system environment.

Understanding Segmentation Fault

As already discussed, when a process’s attempt to access a memory location is out of protocol (e.g overwriting a systemfile or a write attempt to a read-only file) then a segmentation fault occurs.

Since Linux is part of the Unix family of operating systems, when segfault occurs, SIGSEGV (signal #11) is defined in a signal.h (system header file) is called and sent to the process associated with the segmentation fault.

This signal’s default action is to initiate an abnormal termination which then ends the running process. In the case of this process ending its run, a write operation may take place on the primary application’s core file (completely dependent on the current system configuration). Linux architectures like x86_64, the generation of a segfault leads to the kernel ring buffer receiving a log message from the system kernel.

What Causes Segmentation Faults?

Three main circumstances can be associated with the occurrence of segmentation fault.

• Software Defect or a Bug – Sometimes a command or a running program encounters a bug or a software defect. A perfect example is during buffer overflow where an end-of-array memory access attempt takes place. A typical solution to such a problem is implementing vendor software updates.
• Hardware Problem – When the machine you are using to run your Linux operating system distribution has hardware issues (incompetent hardware), its effect will be felt by the virtual memory subsystem. Such hardware incompetency can be associated with defective CPU cache or RAM DIMM.
• Executing an Incomplete Program – When a program is not built/compiled correctly and its execution initiated, the occurrence of a segmentation fault becomes inevitable.

The Implication of a Segmentation Fault

We should never interpret a segfault as a kernel error but as a particular process/program error. The system kernel’s role in dealing with segmentation faults is to detect the associated programs’ errors.

In some Linux architectures, the system kernel is privileged enough to print more segfault-related info like PID and process name. If the segmentation fault is linked to multiple unrelated processes, then the virtual memory subsystem is affected by a hardware issue.

A segmentation fault can be programmatically fixed by checking array boundaries, indirect memory allocation (e.g via smart pointers), and shying away from the use of direct pointer arithmetic (an approach reserved for experienced system programmers).

We are now familiar with the concept of a segmentation fault in a Linux operating system environment.

Источник

Segmentation fault (core dumped) — to where? what is it? and why?

Usually you only need the command gdb path-to-your-binary path-to-corefile , then info stack followed by Ctrl-d . The only worrying thing is that core-dumping is a usual thing for you.

Not so much usual, more occasional — most of the time it’s due to typos or something I changed and didn’t preempt the outcome.

4 Answers 4

If other people clean up .

. you usually don’t find anything. But luckily Linux has a handler for this which you can specify at runtime. In /usr/src/linux/Documentation/sysctl/kernel.txt you will find:

core_pattern is used to specify a core dumpfile pattern name.

• If the first character of the pattern is a ‘|’, the kernel will treat the rest of the pattern as a command to run. The core dump will be written to the standard input of that program instead of to a file.

According to the source this is handled by the abrt program (that’s Automatic Bug Reporting Tool, not abort), but on my Arch Linux it is handled by systemd. You may want to write your own handler or use the current directory.

But what’s in there?

Now what it contains is system specific, but according to the all knowing encyclopedia:

[A core dump] consists of the recorded state of the working memory of a computer program at a specific time[. ]. In practice, other key pieces of program state are usually dumped at the same time, including the processor registers, which may include the program counter and stack pointer, memory management information, and other processor and operating system flags and information.

. so it basically contains everything that gdb needs (in addition to the executable that caused the fault) to analyze the fault.

Yeah, but I’d like me to be happy instead of gdb

You can both be happy since gdb will load any core dump as long as you have a exact copy of your executable: gdb path/to/binary my/core.dump . You should then be able to analyze the specific failure instead of trying and failing to reproduce bugs.

Thanks for this. I’m long used to ulimit -c for controlling the production of core files, but some system builder seems to think that /proc/sys/kernel/core_pattern = |/bin/false was a good idea. Pffftt!

Also, if ulimit -c returns 0 , then no core dump file will be written.

You can also trigger a core dump manually with CTRL — \ which quits the process and causes a core dump.

If ulimit -c returns 0 , you can enable core dumps for that terminal by calling ulimit -c unlimited , as your source says. This sets the max allowed core file size to unlimited .

The core file is normally called core and is located in the current working directory of the process. However, there is a long list of reasons why a core file would not be generated, and it may be located somewhere else entirely, under a different name. See the core.5 man page for details:

DESCRIPTION

The default action of certain signals is to cause a process to terminate and produce a core dump file, a disk file containing an image of the process’s memory at the time of termination. This image can be used in a debugger (e.g., gdb(1)) to inspect the state of the program at the time that it terminated. A list of the signals which cause a process to dump core can be found in signal(7).

.

There are various circumstances in which a core dump file is not produced:

 * The process does not have permission to write the core file. (By default, the core file is called core or core.pid, where pid is the ID of the process that dumped core, and is created in the current working directory. See below for details on naming.) Writing the core file will fail if the directory in which it is to be created is nonwritable, or if a file with the same name exists and is not writable or is not a regular file (e.g., it is a directory or a symbolic link). * A (writable, regular) file with the same name as would be used for the core dump already exists, but there is more than one hard link to that file. * The filesystem where the core dump file would be created is full; or has run out of inodes; or is mounted read-only; or the user has reached their quota for the filesystem. * The directory in which the core dump file is to be created does not exist. * The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size) resource limits for the process are set to zero; see getrlimit(2) and the documentation of the shell's ulimit command (limit in csh(1)). * The binary being executed by the process does not have read permission enabled. * The process is executing a set-user-ID (set-group-ID) program that is owned by a user (group) other than the real user (group) ID of the process, or the process is executing a program that has file capabilities (see capabilities(7)). (However, see the description of the prctl(2) PR_SET_DUMPABLE operation, and the description of the /proc/sys/fs/suid_dumpable file in proc(5).) * (Since Linux 3.7) The kernel was configured without the CONFIG_COREDUMP option. 

In addition, a core dump may exclude part of the address space of the process if the madvise(2) MADV_DONTDUMP flag was employed.

Naming of core dump files

By default, a core dump file is named core, but the /proc/sys/kernel/core_pattern file (since Linux 2.6 and 2.4.21) can be set to define a template that is used to name core dump files. The template can contain % specifiers which are substituted by the following values when a core file is created:

 %% a single % character %c core file size soft resource limit of crashing process (since Linux 2.6.24) %d dump mode—same as value returned by prctl(2) PR_GET_DUMPABLE (since Linux 3.7) %e executable filename (without path prefix) %E pathname of executable, with slashes ('/') replaced by exclamation marks ('!') (since Linux 3.0). %g (numeric) real GID of dumped process %h hostname (same as nodename returned by uname(2)) %i TID of thread that triggered core dump, as seen in the PID namespace in which the thread resides (since Linux 3.18) %I TID of thread that triggered core dump, as seen in the initial PID namespace (since Linux 3.18) %p PID of dumped process, as seen in the PID namespace in which the process resides %P PID of dumped process, as seen in the initial PID namespace (since Linux 3.12) %s number of signal causing dump %t time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC) %u (numeric) real UID of dumped process 

Источник

What is a segmentation fault?

In Ubuntu I have faced the segmentation fault error many times. What is a segmentation fault and when does it occur?

Just to cover it up: I had a similar problem, whereas my segfaults were not reliably reproduceable and they came from (almost) random applications. Found out that most likely my memory is broken. So if quite any program causes segfaults, one might have a closer look at the RAM.

3 Answers 3

An error saying segmentation fault (or segfault, or SIGSEGV) in Ubuntu and other Unix-like operating systems, or saying general protection fault in Windows, is when a program attempts to access a part of memory that cannot be accessed, or which the program is prohibited from accessing. A segmentation fault is a kind of program crash, that is, an abnormal termination of a program. See the Wikipedia articles on crashes, memory protection, segmentation fault, general protection fault, and SIGSEGV for more information (and a more textured understanding of the topic than is presented here).

A segmentation fault is almost always due to a bug in the program where it occurs. I am guessing most or all of your segmentation faults are happening from the same application. Please provide more details about the circumstances under which segmentation faults are happening on your machine, and what program is crashing. Please also provide the full and exact text of the error message you’re receiving and any other messages that appear before it. This should make it possible for us to provide detailed advice specific to your problem (rather than just general information about what a segmentation fault is).

The best way for you to provide this information is for you to edit your question to include it. Alternatively, if you want this question to be just about segmentation faults in general, you could post a new question to ask about what specifically is causing your segmentation faults (if you do this, make sure to provide all these details in your new question).

Источник