Segmentation fault

[iammilind]

-> Is there any standard for when a sementation fault can occur; I mean should it occur if we access 0, or code segment or anything else ?

-> Why a system crashes, when we are trying to just "read" a memory area which is protected ?
(I can understand that system should crash if we try to "write" something.)

-> How the system knows that, we are accessing a prohibited area; will it check that before accessing any pointer ? If that is so, won't it be time consuming ?

[donbock]

The unary * operator denotes indirection. ... If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined. (83)

83) ... Among the invalid values for dereferencing a pointer by the unary * operator are a null pointer, an address inappropriately aligned for the type of object pointed to, and the address of an object after the end of its lifetime.

Segmentation fault is not mentioned in the Standard. The Standard allows anything to happen if you dereference an invalid pointer -- including segmentation fault. Notice the Standard does not require undefined behavior to be consistent -- some invalid pointers may cause segmentation faults, while others may not.

The Standard says that both read and write through an invalid pointer are undefined behavior.

Not all systems provide segmentation faults. Typically, segmentation fault is only supported by systems where it is easy to detect use of invalid pointers; for example target systems with a memory management unit (MMU).

Why should anybody care if you merely read through an invalid pointer? Some processors use an asynchronous bus architecture -- memory access timing is nondeterministic, the access completes when the memory device announces it is finished. What if you access nonexistent memory? There is no memory device to announce completion of the access. Rather than hang forever, these processors have a failsafe timer that aborts bus transactions that take too long. Triggering the failsafe timeout (called 'bus error') is a pretty serious exception. Another reason not to go off and read arbitrary memory is memory-mapped I/O. Some I/O devices change state when you read them; for example, reading the receive-register of a UART causes the received character to be discarded.

[iammilind]

Thanks Donbock. Can you also clarify my third question that, how does a system know if to cause a "seg fault" when prohibited memory is accessed ?
for example, following code caused seg. fault:

int *p = 0x<CODE_SEGMENT>;
int i = *p; // seg. fault

Will system always check if the 'p' is between the protected areas of code segment. And if this is the case, aren't we compromising the execution time at a large extent ?

[Banfa]

Generally segmentation faults come from software or hardware subsystems that have to perform address translation of some sort. When handed an invalid address they can't do it and raise an exception in hardware that is ultimately translated into a seg fault in software.

Platforms that don't have this sort of address translator generally don't produce seg faults, just very strange behaviour as you read and write memory that you shouldn't be.

[donbock]

The C Standard neither requires nor forbids an implementation to embed the type of run-time checking that you propose. As a practical matter, I don't think you will find any compilers that spontaneously inject run-time pointer-validation code. As Banfa pointed out, all run-time ponter checking we're aware of is performed by hardware.

[Frinavale]

I'm curious.

I'm I correct in saying that it is the Operating System that determines when your application is attempting to access memory outside of what has been allocated for use by the application?

It is the OS that creates the core dump files...right?

-Frinny

[weaknessforcats]

I believe so. Once version of Windows checked the value of the CR12 register after the translation from the logical to the physical disk address. If that register changed, then the address was outsode the process address space and triggered an access violation.

[Banfa]

Not necessarily, for instance I have worked with plenty of embedded applications that had no operating system as such, apart from the fairly basic multi-threading one used such ThreadX. However they did have a hardware memory management units.

As far as the processor and operating system was concerned any address is valid but the memory management unit which is a hardware component within the processor is aware of what logical addresses map to actual physical addresses and raises an actual hardware interrupt on the processor when it tries to access and address that maps nowhere.

My point here Frinny is that you are making a common oversight of assuming that when talking C/C++ the platform is a PC of some sort but actually that is an extremely limit view of the possible platforms that run code compiled from C/C++. I suspect that C/C++ is used in writing code for a wider range of platforms than almost any other language from 8 bit microprocessors limited to a few kbytes of internal memory up through PCs and beyond.

Trying to generalise about the actions of such a wide variety of operating systems is at best unlikely to cover the full range of possibilities.

[Frinavale]

Thanks Banfa :)

-Frinny