Thread: Easy safe memory allocator class/functions

Hi. As some of you may know I am attempting to get various debugging tools turned into headers for inclusion of a project. This time around I started making a smartptr that could:

1. Allocate a new object of type T
2. If that object is used to access memory outside of the ptr buffer it could throw an assertion.

By way of example if:

Code:

// old way
int numElements = 5;
double *ptrDoubleArray  = new double[numElements];
// accessed like
ptrDoubleArray[4] = 5; // okay
ptrDoubleArray[10] = 5; // is not OK

// With smartptr
SmartPtr ptrSmart = new double[numElements];
ptrSmart[4] = 5; //still OK
ptrSmart[20] = 5; //smart ptr knows it "owns" addresses ptrSmart to ptrSmart + 5
                             // so with an overloaded [] operator, it will internally do
if( newRequestedElement > ptr + 5)
{   
      assert();
}
else
{
      return ptr[newRequestedElement];
}

So that logic (roughly) will tell me if an attempt to access the ptr is outside of its range plus the usual stuff a smart ptr does. However what I want to do now is detect when:
1. The pointer itself is damaged.
2. The data underneath the pointer has been stepped on
3. The pointer itself has been damaged.

I have theories on how to do this but would like to know either if
A. I am nuts for trying this...wait scratch that.
B. There is something like this out there.

My theory is to use basic memory protection techniques:
When the smart pointer does the basic allocation, it allocates memory sizeof(class T) plus two blocks at the beginning and end of that block 2*sizeof(classT) and here is the trick: when I allocate the memory with the guard buffers as described above, I cope the value of the actual ptr into both ends of the memory window. Further when the class is used normally a hash of the original memory block. The at periodic times in the source you can call checkPtr(someSmartPtr) which will compare the guards at the front and end of the memory block with the value of the actual ptr. If one of the guards and the ptr match but not the other one, it will assert with a stacktrace saying "Beginning" (if that is the odd-man out) or "End" if the latter guard doesn't match "Has been overwritten in file XXX.cpp on line YYY".
If that is OK, the actual memory window is rehashed and if the hash value doesn't match the previous check, it reports that memory has been stepped on. No idea how to tell who did it yet but this is a start. If the value of the ptr and the beginning and ending guards match AND the checksum is correct it will return a success value.

Not as good as a memory tool but could be useful.

So does something like this exist?

TIA
Jeff

Originally Posted by salquestfl

Why not use a vector?

In what way would a vector address any of those requirements? Boundary checking, data corruption checking, etc?

Originally Posted by jeffcobb

In what way would a vector address any of those requirements? Boundary checking, data corruption checking, etc?

A vector would address boundary checking if you stick to the use of at(), but not the others.

Originally Posted by jeffcobb

I have theories on how to do this but would like to know either if
A. I am nuts for trying this...wait scratch that.
B. There is something like this out there.

I'm aware of a couple of small home-grown libraries that tried to do this sort of thing, but the authors eventually gave up (I'll try to find them - if I succeed, I'll follow up with pointers). The basic problem is that code which does an invalid pointer operation can potentially tromp on anything. No matter what scheme you use to detect corruption, there is always a likelihood some false negatives (a case that passes your test, but tromps something) exist.

The reason such operations are classified as "undefined behaviour" by the C and C++ standards is that it is extremely difficult, if not impossible, for a compiler to identify the full range of possible erroneous behaviours.

I don't think you're nuts for wanting to do this, but I do think - if you proceed - you will suffer tremendous frustration. Every time you think you have covered the bases, it will be possible to find some erroneous code that sails through your tests.

Unfortunately, the only way to offer robust assurances that some code does not perform invalid operations is the hard way: rigorous analysis to ensure that a design eliminates unwanted errors, rigorous review of code to ensure it doesn't violate some assumption of the design, etc. Assurance processes are facilitated by ensuring the design is as simple as possible (i.e. avoid unnecessary complexity) but, in the end, it comes down to hard work. It is no accident that safety-critical code averages a much higher cost per line of code than does the code in a typical MP3 player - it takes significant effort to give higher levels of assurance.

Writing tools (or debugging headers, in your case) simply shifts the focus of effort because the tool itself must be subjected to rigorous assurance processes. Increase the general-purpose nature of the tool (which would be necessary if you seek to over a wide range of arbitrary invalid operations), and more effort is needed to offer assurance that the tool covers all bases in a reliable manner.

That doesn't mean you shouldn't try.

The worst case result of your effort is that you will learn a lot: you will certainly gain broader insights into the way invalid operations can manifest. Which will help your future work, as you will tend to design and code your software in a way that reduces likelihood of squirrelly errors. Hence, even if you fail, you'll become a better developer. If you succeed, you'll prove my scepticism wrong - which I won't complain about, as it'll mean you have made some valuable contribution or breakthrough in the state of the art for detecting errors in software.