Is there any way to check if pointer is dangling?

Question

I have a code where I use a pointer to access some datablock. In some rare cases, a few members of the datablock are empty, and as a result the pointer becomes dangling. In fact, I get the correct pointer but the program crashes when trying to do something with the pointer.

The usual advice would be to avoid this type of usage. But sadly, the framework I use requires that I use this type of data access methods.

Is there a way I can "check" if the pointer is invalid before doing any operation with it? Checking that the pointer is not equal to NULL did not work, obviously. I also tried this:

try
{
    CString csClassName = typeid(*pMyPointer).name();  // Check error condition
    // The line below fails due to dangling pointer (data block is not valid).
    hr = pMyPointer->MyPointerMethod(); 
}
catch(bad_typeid)
{
    return E_FAIL;
}
catch(...)
{
    return E_FAIL;
}

Is it the correct way?

Immingle

Answer 1

There's no way to check whether or not a raw pointer is valid. Invalid pointers are not guaranteed to fail when you access them. Instead of using a raw pointer, you need to use some form of smart pointer.

Spunky

My pointer should be static to the class..is it still fine If i use smart pointers? – Immingle

That's no problem at all. You need to watch out for thread safety issues but that's no different for a smart pointer vs a raw pointer. – Spunky

I don't think it matters. The only thing that bothers me is whether your framework can itself make your pointers dangling without any prior notice. See, you'll have to extract the raw pointer out of the smart pointer and pass it to your framework. If it guarantees either that the pointer will remain valid after the call, or that you will be informed should it become invalid - fine, go for it. – Inappreciable

Answer 2

I think you are looking at the wrong direction. You probably have a bug by which you are not correctly initializing the pointers, deleting the objects too early and trying to reuse the pointer after it has been deleted or something alike. If that is the case, you should focus on determining why that is happening and fixing the bug, rather than trying to find a way of hiding the bug.

As of the approach that you are using with the typeid operator, the answer is that it is not valid. For objects of types that don't contain virtual functions, the typeid operator is resolved at compile time based on the static type of the pointer. For objects that contain at least one virtual function, it is resolved at runtime, but calling typeid(p) with an invalid pointer is undefined behavior, and in the same way that it seems to work it might crash.

The use of smart pointers that has been suggested, might depend on what the library actually does and whether you can pass around the smart pointers at all times or not. In general it is a good idea to use smart pointers for memory management, and that will in turn guarantee that the pointers will be correctly initialized (fix if the problem is initialization) and because you no longer delete manually, chances are that if the problem is with early deletion that will no longer happen. But note that while this might solve the issue, I still think that you need to understand why the pointer is invalid in your application, as that might be a symptom of a greater problem.

Now, on the original question of how to check whether the pointer is dangling or not, you cannot do it in the program, but you can run your program inside memory debuggers (valgrind in linux, Purify or a set of others in linux) and the tool will be able to help you determining whether the pointer was never initialized, or if you released the memory to the system before the incorrect use.

Rousing

Thanks for your detailed explanation.I can understand that i should find a solution instead of hiding the bug...But there is a loophole in framework designed which I can not change in short time.so i was looking for workaround for time being.I tried with smart pointers also but it didn't work out. – Immingle

Answer 3

Yes, you can use smart pointers.

Inappreciable

Answer 4

You don't need smart pointers. They are just one possible approach to dealing with this problem.

You could use reciprocal references: Within the referenced object (referencee), a list of references back to those objects that reference it (referencers). When it is time to deallocate the referencee, first run through its list of referencers and set any properties in which they use to point to the referencee, to null (typically you'd want to know beforehand which property this would be), then deallocate the referencee.

Conclude