Misplaced Pages

Storage violation: Difference between revisions

Article snapshot taken from Wikipedia with creative commons attribution-sharealike license. Give it a read and then ask your questions in the chat. We can research this topic together.
Browse history interactively← Previous editContent deleted Content addedVisualWikitext
Revision as of 14:17, 2 October 2009 editBeno1000 (talk | contribs)Pending changes reviewers3,659 editsmNo edit summary← Previous edit Latest revision as of 06:21, 22 April 2024 edit undoClueBot NG (talk | contribs)Bots, Pending changes reviewers, Rollbackers6,438,440 editsm Reverting possible vandalism by 37.186.61.151 to version by Onel5969. Report False Positive? Thanks, ClueBot NG. (4316824) (Bot)Tag: Rollback 
(24 intermediate revisions by 16 users not shown)
Line 1: Line 1:
{{Short description|Hardware or software fault}}
A '''storage violation''' occurs when a ] modifies, or attempts to modify, ] that it does not own. In ] a '''storage violation''' is a hardware or software ] that occurs when a ] attempts to access an area of ] which it is not permitted to access.


==Types of storage violation== ==Types of storage violation==
Storage violation can, for instance, consist of writing to or freeing storage not owned by the task. Storage violation can, for instance, consist of reading from, 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 exceed the limits set for its ]. It can also refer to attempted modification of memory "owned" by another thread where there is incomplete (or no) memory protection.

A common type of storage violation is known as a ] where a program attempts to alter a memory location beyond its allocated memory.


==Avoidance of storage violations== ==Avoidance of storage violations==
⚫ 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 ].

⚫ 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 ].


==Detection of storage violations== ==Detection of storage violations==
Storage violations can be difficult to detect as a program can often run for a period of time after the violation before it crashes. For example, a pointer to a freed area of memory can be retained and later reused causing an error. As a result, efforts focus on detecting violations as they occur, rather than later when the problem is observed.
⚫ In systems such as CICS, storage violations are sometimes detected (by the CICS ]) by the use of "signatures", which can be tested to see if they have been overlaid.


⚫ In systems such as CICS, storage violations are sometimes detected (by the CICS ]) by the use of "signatures", which can be tested to see if they have been overlaid.

An alternative runtime library may be used to better detect storage violations, at the cost of additional overhead.<ref>{{cite web|url=http://dmalloc.com|website=Dmalloc - Debug Malloc Library| title= Debug Malloc Library|access-date=2017-04-26}}</ref>
Some programming languages use software ] to prevent these occurrences. 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.

==Common causes==
*A runaway subscript leading to illegal use of reference modification during run time.
*Linkage layout mismatch between called and the calling elements.
*Use of previously freed (and sometimes already re-allocated) memory.

===Examples of software detecting storage violations=== ===Examples of software detecting storage violations===
⚫ *] originally from Online Software International, later ]
* ] from APT UK, later ] which used used an ]

⚫ * ] originally from Online Software International , later ]
==See also==
*]


==References== ==References==
{{Reflist}} {{Reflist}}
⚫ *{{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}}
*


==External links==
⚫ {{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 }}
*https://plus.google.com/u/1/collection/wUwasB Marketing material for other product detecting storage violations

⚫ {{compsci-stub}}


] ]
] ]


⚫ {{compsci-stub}}

Latest revision as of 06:21, 22 April 2024

Hardware or software fault

In computing a storage violation is a hardware or software fault that occurs when a task attempts to access an area of computer storage which it is not permitted to access.

Types of storage violation

Storage violation can, for instance, consist of reading from, 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 exceed the limits set for its call stack. It can also refer to attempted modification of memory "owned" by another thread where there is incomplete (or no) memory protection.

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

Storage violations can be difficult to detect as a program can often run for a period of time after the violation before it crashes. For example, a pointer to a freed area of memory can be retained and later reused causing an error. As a result, efforts focus on detecting violations as they occur, rather than later when the problem is observed.

In systems such as CICS, storage violations are sometimes detected (by the CICS kernel) by the use of "signatures", which can be tested to see if they have been overlaid.

An alternative runtime library may be used to better detect storage violations, at the cost of additional overhead. Some programming languages use software bounds checking to prevent these occurrences.

Some program debugging software will also detect violations during testing.

Common causes

  • A runaway subscript leading to illegal use of reference modification during run time.
  • Linkage layout mismatch between called and the calling elements.
  • Use of previously freed (and sometimes already re-allocated) memory.

Examples of software detecting storage violations

See also

References

  1. "Debug Malloc Library". Dmalloc - Debug Malloc Library. Retrieved 2017-04-26.

External links


Stub icon

This computer science article is a stub. You can help Misplaced Pages by expanding it.

Categories: