CODEWITHSUNDEEP
cmemory-managementoperating-systemsegmentation-fault
Venkat
Venkat

Reputation: 181

Are segmentation faults thrown before or after memory is modified?

This is a purely academic question but i understand that segmentation faults are thrown by the OS when a request is made to access memory which the program doesn't have access to.
My question is Will there be some memory modification or will the OS prevent all illegal behavior?

Also if the OS prevents the memory from being corrupted isn't it better to attempt to catch and recover from the segmentation fault rather than close the program (consider a critical program)?

Upvotes: 2

Views: 127

Answers (2)

sh1
sh1

Reputation: 4731

If an illegal write is detected, it will almost certainly be stopped by the hardware. If the address is completely invalid then the hardware will raise a fault because it has no idea what else it can do (there is no memory there, so you can't corrupt it). If it's marked as read-only then the hardware should block the write and raise the fault, but that does depend on the hardware (you'd be using a fairly specialist system to see any other behaviour).

There are, however, cases where the illegal write is not detected. That is, the hardware can't tell the difference and doesn't bother to mention it. This is because the hardware operates in pages (typically 4kB large), but your data structures don't all start and stop at those page boundaries. If there's leftover space between the end of valid memory and the end of the page, then writes into that space will be un-guarded.

Also, the write might be to memory which is owned by the application, but where the application has no business writing. There are data structures in the heap, for example, which are manipulated by library code under the same system privileges as the application, but if the application (rather than the library) attempted to write to it it would be a clear sign of misadventure. The hardware cannot necessarily see the difference, and so no fault is raised.

As for trying to trap and recover... It's rare that the application is in any fit state to carry on. For every write you can detect, there may have been many more that slipped through the cracks, causing undetected corruption and making the problem much worse. Even if the very first faulty access is detected, such that no memory has been corrupted, there's usually no way to figure out what the application should have done instead.

Allowing the application to carry on will probably result in more faults and progressively more nonsense behaviour until it does harm to the system (using up all the CPU, writing garbage to files, drawing garbage on the screen, copying sensitive information to public places, etc.). Conversely, killing it dead and starting it up again from a known state should result in more predictable behaviour.

As an aside; detecting faults at the hardware level and carrying on is actually something that is done silently by the OS, but only under specific conditions. Initially only a small amount of memory is allocated to an application. If the application makes reference to something which hasn't been mapped to it yet then the hardware will raise a fault (as above) but the OS will inspect the situation and determine if the access is memory which the application should be allowed to use or if it was a mistake. In the former case it'll reconfigure the hardware to map memory into the correct place and allow the application to continue as if nothing had happened.

Upvotes: 3

junix
junix

Reputation: 3211

Short answer: Yes, Segmentation faults are thrown before Memory is modified.

The long answer goes into the inner workings of virtual memory and/or memory protection. You can imagine memory as split into multiple blocks. For each block the operating system can setup a several attributes like no execution, no write, no read, etc.

These attributes are parsed by the Memory Protection Unit (MPU) or the MMU and checked before the real access takes place. In case the attempted access violates the Setup restrictions, the MMU stops execution and signals the operating system to handle the situation.

The operating system then usually stops the process causing this signal.

It is important to know that this mechanism is page based. This means you can't catch things like "array out of bounds" or similar effects. It's a very coarse grained tool that helps to keep integrity of code pages vor example.

Upvotes: 2

Related Questions