Dangling Pointer

rolph1 pts0 comments

Dangling pointer - Wikipedia

Jump to content

Search

Search

Donate

Create account

Log in

Personal tools

Donate

Create account

Log in

Dangling pointer

13 languages

العربية<br>Català<br>Deutsch<br>Español<br>فارسی<br>Français<br>Italiano<br>한국어<br>Монгол<br>Português<br>Русский<br>Українська<br>中文

Edit links

From Wikipedia, the free encyclopedia

Pointer that does not point to a valid object

Dangling pointer

Dangling pointers and wild pointers in computer programming are pointers that do not point to a valid object of the appropriate type. These are special cases of memory safety violations. More generally, dangling references and wild references are references that do not resolve to a valid destination.

Dangling pointers arise during object destruction, when an object that is pointed to by a given pointer is deleted or deallocated, without modifying the value of that said pointer, so that the pointer still points to the memory location of the deallocated memory. The system may reallocate the previously freed memory, and if the program then dereferences the (now) dangling pointer, unpredictable behavior may result, as the memory may now contain completely different data. If the program writes to memory referenced by a dangling pointer, a silent corruption of unrelated data may result, leading to subtle bugs that can be extremely difficult to find. If the memory has been reallocated to another process, then attempting to dereference the dangling pointer can cause segmentation faults (UNIX, Linux) or general protection faults (Windows). If the program has sufficient privileges to allow it to overwrite the bookkeeping data used by the kernel's memory allocator, the corruption can cause system instabilities. In object-oriented languages with garbage collection, dangling references are prevented by only destroying objects that are unreachable, meaning they do not have any incoming pointers; this is ensured either by tracing or reference counting. However, a finalizer may create new references to an object, requiring object resurrection to prevent a dangling reference.

Wild pointers, also called uninitialized pointers, arise when a pointer is used prior to initialization to some known state, which is possible in some programming languages. They show the same erratic behavior as dangling pointers, though they are less likely to stay undetected because many compilers will raise a warning at compile time if declared variables are accessed before being initialized.[1]

Cause of dangling pointers<br>[edit]

In many languages (e.g., the C programming language) deleting an object from memory explicitly or by destroying the stack frame on return does not alter associated pointers. The pointer still points to the same location in memory even though that location may now be used for other purposes.

A straightforward example is shown below:

char* dp = NULL;<br>// ...<br>char c;<br>dp = &c;<br>// c falls out of scope<br>// dp is now a dangling pointer

If the operating system is able to detect run-time references to null pointers, a solution to the above is to assign 0 (null) to dp immediately before the inner block is exited. Another solution would be to somehow guarantee dp is not used again without further initialization.

Another frequent source of dangling pointers is a jumbled combination of malloc() and free() library calls: a pointer becomes dangling when the block of memory it points to is freed. As with the previous example one way to avoid this is to make sure to reset the pointer to null after freeing its reference—as demonstrated below.

\n\nvoid func() {\n char* dp = (char*)malloc(sizeof(char) * 10);\n // ...\n free(dp); // dp now becomes a dangling pointer\n dp = NULL; // dp is no longer dangling\n // ... \n}\n"}}'>#include

void func() {<br>char* dp = (char*)malloc(sizeof(char) * 10);<br>// ...<br>free(dp); // dp now becomes a dangling pointer<br>dp = NULL; // dp is no longer dangling<br>// ...

An all too common misstep is returning addresses of a stack-allocated local variable: once a called function returns, the space for these variables gets deallocated and technically they have "garbage values".

int* func(void) {<br>int num = 1234;<br>// ...<br>return &num;

Attempts to read from the pointer may still return the correct value (1234) for a while after calling func, but any functions called thereafter may overwrite the stack storage allocated for num with other values and the pointer would no longer work correctly. If a pointer to num must be returned, num must have scope beyond the function—it might be declared as static.

Manual deallocation without dangling reference<br>[edit]

Antoni Kreczmar [pl] (1945–1996) has created a complete object management system which is free of dangling reference phenomenon.[2] A similar approach was proposed by Fisher and LeBlanc[3] under the name Locks-and-keys.

Cause of wild pointers<br>[edit]

Wild pointers are created by omitting necessary initialization prior to first use. Thus, strictly speaking, every pointer in programming...

dangling pointer pointers memory object char

Related Articles