> A segment violation is an access violation on a page of memory, commited
> by the program or by the kernel. A sigsegv done by a user program causes
> a special piece of code in the kernel to trigger and to stop the user's
> task, by delivering a SIGSEGV to it.
To be more accurate, it ONLY sends it SIGSEGV. The part that might, and
might not, stop the program, is that next time the process is scedualed,
it checks for signals, and if there was some signal there, it is handle
appropriatly, not neccerily stopping the program.
> By default, when this happens, a core
> file is generated and the program stops abruptly (w/o saving data etc).
> The program can catch SIGSEGV and prevent the core dump. That is all it
> can do, and it MUST exit. There is no way a SIGSEGV handler can return to
> the program (well, almost ;).
There are two easy ways for SIGSEGV to return to the program.
At least on solaris, you can tell the OS to return whatever value as the
result of the illegal memory read, or in a case of a write, not to do
anything.All this
in the SIGSEGV handler. It is very usefull if you are willing to sacrifise one
part of the data to be incorrect in order for the program to be kept alive.
Some program MUST keep running.
A second easy way is to use longjmp().
>
>
> When a kernel subroutine generates a segmentation violation, then a
> so-called OOPS (oops = Linux slang for small turd afaik) is generated.
> This appears in the syslogs.
Huh? When a Kernel causes a trap, the kernel panics.
For example, if there is a trap in the write() kernel code, how
exactly you are going to write to the syslog ?
Maybe you are confused by seeing messages that comes out as a
result of a kernel function checking out if a pointer is correct before
using it. If not, it sends a message to syslog.
>
> The reasons for segment violations are two, and two only: poor programming
> practice (buggy programs) or hardware faults.
>
> At the hw level: The addressable memory on an Intel proecssor is divided
> into pages (currently 4k each ?).
You mean the i386 and on, not ANY Intel. And this is true only if the
CPU is on protected mode and if the paging is on.
> This is the minimum size of any
> allocated memory, file, program etc.
Not true. For example, the minimum allocated size of a file is 512 bytes.
And even this is based on the filesystem.
> Each page has read write and exec
> permission bits (among others). When a program or the kernel code tries to
> use a page as source or target for something that its protection bits say
> it can't be used, then a segmentation fault occurs.
Not true.
A Segmentation Fault is a UNIX idea. What happen on a processor, is a trap.
You can have a trap, but the kernel will NOT allways send a Segmentation
Fault ! For example, if COW is used.
Do not Mix Segmentation Fault or Bus Eror WIth trap types 11,12,13,14 and 17.
> This is a hardware
> event in which the processor refuses to execute the offending instruction,
> and executes the segmentation fault error handler instead. That one makes
> the oops or causes the SIGSEGV or the core dump, depending on what eactly
> caused the event. Page permission bits are set by the kernel paging
> functions, and/or by certain other kernel utilities (INSIDE the kernel).
>
This is way to simplistic. But basicly it's ture.
>
> Typical examples for page permission bit use, is the non-exec stack patch,
> a Linux security enhancement. It resets the exec bit of all the pages that
> belog to the stack memory (which are by default rwx normally).
>
> The best way to avoid sigsegvs is to keep track of ALL of your pointers in
> C code (and what they are pointing to). This includes range and size
> checks on every increment/decrement, cast, etc.
>
> bye,
>
> Peter
