Home > Net >  how to monitor dangling pointers that points to leakded memory?
how to monitor dangling pointers that points to leakded memory?

Time:04-22

lets think we have a code like this :

 int * ptr = new int;
 int *nptr = ptr
 int * ptr2 = new int;
 int *nptr2 = 2*nptr ptr2;
 delete ptr;
 delete ptr2;
 ptr = NULL;
 ptr2 = NULL;

So now the nptr and nptr2 is dangling pointer .I know that we can overload new allocating function to trace leaked memory (if we dont use delete command in code ) but dont know how to trace or monitor dangling pointers .

CodePudding user response:

dangling pointers that points to leakded memory?

A pointer that has leaked, by definition is not being pointed by anything. A dangling pointer by definition points to memory that hasn't been leaked. This is a contradiction.

int *nptr2 = 2*nptr ptr2;

This is ill-formed. Pointers cannot be multiplied by integers, and pointers cannot be added to pointers (I'm assuming the assumption is that result of the ill-formed multiplication is also a pointer). Furthermore, if this pointer arithmetic produced anything other than nptr, nptr 1, nptr2, nptr2 1, then the result would technically be undefined.

but dont know how to trace or monitor dangling pointers .

It's perfectly fine and normal to have dangling pointers. What isn't fine is indirecting through dangling pointers or relying on their value. At least for indirection, you can use an address sanitiser to try catch such bugs. It can find some uses of dangling pointers particularly those to dynamic memory such as the pointers in the question. It's not as good at detecting dangling pointers to automatic variables. On the other hand, compiler can catch simple cases such as returning pointer to local variable.

Alternatively, you can modify your program to use std::shared_ptr so that as long as you still hold a shared pointer, it cannot become dangling. This comes at a small cost of overhead, but it makes it much easier to reason about lifetime correctness.

CodePudding user response:

First of all "dangling pointers that points to leakded memory" makes no sense. I suppose you mistakenly use "leaked memory" for objects that are already destroyed. In your code there is no memory leak. You have a memory leak when you do not have a pointer to some dynamically allocated obejct anymore, as in:

{
    int* x = new int;
} // x goes out of scope, no way to delete the int 

Further, it is not clear what this line is supposed to do int *nptr2 = 2*nptr ptr2;. It is not valid C , hence I am going to ignore it for the rest of the answer. Also the last two lines are not that relevant (maybe for code that comes after the shwon code but not here).

So we are left with:

 int * ptr = new int;
 int *nptr = ptr
 int * ptr2 = new int;
 delete ptr;
 delete ptr2;

You create two int via new. You delete two int. No memory is leaked. After delete ptr the pointer nptr points to a no longer existing object. nptr is said to be a dangling pointer.

With that out of the way, we can turn to your actual question: How to monitor dangling raw pointers?

You cannot. A raw pointer is rather primitive. It stores an address. And thats all. The pointer is not aware whether there is an object at that adress or not. This is one reason you should not use new and delete and raw pointers to manage memory. Use smart pointers. For example if you share ownership between two std::shared_ptr then the pointee will be kept alive as long as one of the shared pointers is alive. A shared pointer cannot dangle (unless you do something wrong).

CodePudding user response:

I would recommend that you not use raw pointers. If you use smart pointers that then you will never(*) have a dangling pointer. The whole purpose of smart pointers is to ensure that the lifetime of both the pointer and what is pointed to is managed together.

Use std::unique_ptr, std::shared_ptr (and std::weak_ptr if needed).

You can use tools like Valgrind and AddressSanitizer to ensure that you do not use dangling pointers.

(*) never is perhaps too strong, at least make it more difficult.

  • Related