On Tuesday, 10/28/2003 at 10:49 PST, "Fargusson.Alan"
<[EMAIL PROTECTED]> wrote:
> If I may ramble on a bit: one thing I have noticed is that all systems I
have
> worked with have one common problem, which is programs that try to
access
> memory regions outside of the allocated virtual memory for the process.
On
> Windows this results in the famous general protection fault, on Unix it
results
> in the famous segmentation fault, and on z/OS it is the famous SOC4. I
wonder
> if there isn't a better way to deal with this problem then just aborting
the
> program. Users find this problem really annoying.
[0C5, addressing exception, is what you get when you try to access memory
not defined to your address space. 0C4, protection exception, is the
result of trying to read or write memory that *is* part of your address
space but for which memory protection mechanisms are in effect, such as
storage keys and segment protection.]
The problem isn't with the fault. The problem is in how the system
handles it. If the system provides a way for the application to catch it
(VM and MVS do), then you could let the application try to recover, but
such exceptions usually mean the program is hosed in some fashion. Odds
of a successful recovery ("Oops! I'll go back and use the *right* pointer
this time!") are poor.
We separate the sheep from the goats when we look at how the system deals
with such an error. It should, of course, be architecturally impossible
for a wild address to destroy any part of the operating system, including
any list of resources being used by the program. So, the operating system
needs to close files, close sockets, release memory, decrement shared
object counters, release held locks, delete semaphores, and so on. As
though the program had Never Been. I've seen less robust operating
systems lock up during this phase, or not clean up everything belonging to
the program, including other programs.
Alan Altmark
Sr. Software Engineer
IBM z/VM Development
