| Revision as of 14:34, 11 October 2008 editPhilKnight (talk | contribs)Checkusers, Oversighters, Administrators125,532 editsm Reverted edits by PhilKnight (talk) to last version by Kubanczyk← Previous edit | Revision as of 20:33, 20 October 2008 edit undoBoson (talk | contribs)Extended confirmed users, Pending changes reviewers17,771 edits Major modification and added referenceNext edit → | ||
| Line 1: | Line 1: | ||
| A ''' |
A '''storage violation''' occurs when a ] modifies ] that it does not own. | ||
| ==Types of storage violation== | |||
| It normally applies to selected memory locations having special significance to the ] or "owned" by a particular ]. | |||
| Storage violation can, for instance, consist of writing to or freeing storage not owned by the task. | |||
| A common type of storage violation is known as a ] where a program attempts to alter a memory location beyond its allocated memory. | |||
| Computer storage (another term for memory), is often dynamically allocated from a ] of available memory for a particular "process" such as a program ] call. For instance, if one ] of memory is available for several concurrent applications to use, each application may request its own 'section' of this memory for its own use. | |||
| ==Avoidance of storage violations== | |||
| The application may further sub-divide its own allocated memory to process internal functions such as saving ], ] and ] images. | |||
| Storage violations can occur in transaction systems such as ] in circumstances where it is possible to write to storage not owned by the transaction; such violations can be reduced by enabling features such as ] and ]. | |||
| A common type of Storage violation is known as a ] where a program attempts to alter a memory location beyond its' allocated memory. For instance, a "storage violation" occurs if the program tries to alter the eleventh ] of an ] ("table") of only 10 entries (elements) in size. Imagine an array of 10 x 4-letter words in an allocated memory of 40 bytes. | |||
| ==Detection of storage violations== | |||
| The memory at the address of the eleventh entry may belong to another application program or another ] of the same application. If this is so, the other application now has corrupted memory without necessarily being aware of it. This has traditionally been the source of many unsolved system crashes within computing and sometimes referred to as "]". The use of ] in some ] makes it easier to corrupt storage if the pointers are incremented beyond their appropriate range at any given point during execution. | |||
| In systems such as CICS, storage violations are detected by the use of "signatures", which can be tested to see if they have been overlaid. | |||
| ⚫ | Some programming languages use software ] to prevent these occurrences. | ||
| Use of a corrupt ] address (sometimes known as a "]") may also result in execution of code which results in possibly random execution of perfectly valid instructions - but almost certainly completely out of context with appropriate register values for that code. In this case, the "]" address may be extremely difficult or even impossible to determine without suitable instruction tracing or monitoring software (but invoked prior to the error occurring - if an exact rerun is even possible - which, in high volume, real-time transaction processing, is seldom the case). | |||
| In some instances, it is necessary to switch into privileged mode to enable storage alteration to be successful. This is normally achieved by a special instruction which itself might be privileged. | |||
| This right or "privilege" may only be authorized for some users or software or systems on a higher level of operation such as the ] itself. | |||
| == Prevention == | |||
| ⚫ | Some programming languages use software ] to prevent these occurrences. | ||
| Some program ] software will also detect violations during testing. | Some program ] software will also detect violations during testing. | ||
| ==References== | |||
| Some ] protection features can be used to prevent these too but generally operate on larger blocks of memory than might be appropriate for a given process. | |||
| {{Reflist}} | |||
| Operating systems generally execute in a "privileged" mode allowing their instructions to alter storage at any location in memory. | |||
| == See also == | |||
| * ] | |||
| * ] | |||
| * ] | |||
| {{unreferenced|date=July 2006}} | |||
| {{cite web | url = http://publib.boulder.ibm.com/infocenter/cicsts/v3r2/index.jsp | title = CICS Transaction Server for z/OS, Version 3 Release 2 Information Center | accessdate = 2008-10-20 | author = IBM | authorlink = IBM | publisher = IBM }} | |||
| {{compsci-stub}} | {{compsci-stub}} | ||
Revision as of 20:33, 20 October 2008
A storage violation occurs when a task modifies computer storage that it does not own.
Types of storage violation
Storage violation can, for instance, consist of writing to or freeing storage not owned by the task.
A common type of storage violation is known as a stack buffer overflow where a program attempts to alter a memory location beyond its allocated memory.
Avoidance of storage violations
Storage violations can occur in transaction systems such as CICS in circumstances where it is possible to write to storage not owned by the transaction; such violations can be reduced by enabling features such as storage protection and transaction isolation.
Detection of storage violations
In systems such as CICS, storage violations are detected by the use of "signatures", which can be tested to see if they have been overlaid.
Some programming languages use software bounds checking to prevent these occurrences.
Some program debugging software will also detect violations during testing.
References
IBM. "CICS Transaction Server for z/OS, Version 3 Release 2 Information Center". IBM. Retrieved 2008-10-20.
 | This computer science article is a stub. You can help Misplaced Pages by expanding it. |