Detecting freed memory

[Rob]

int *p;

p = malloc(1);

free(p);

/* */
In the above code, how do I detect that variable p points to nothing?
In other words, how do I detect a freed memory pointer, as opposed to a
pointer that points to allocated memory?

[EventHelix.com]

There is no general way to do this. One way is to write your own
wrappers around malloc and free and include different signatures in the
buffer that can be checked.

Microsoft Visual C++ compiler does something similar in a Debug build.
When a buffer is freed, it copies a known signature pattern in all the
bytes of the buffer.

--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Generate Sequence Diagrams in PDF and Word EMF from plain text input

[Lew Pitcher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rob wrote:

int *p;

p = malloc(1);

free(p);

/* */
In the above code, how do I detect that variable p points to nothing?
In the above code, you don't (and can't) "detect that variable p points to nothing".
In other words, how do I detect a freed memory pointer, as opposed to a
pointer that points to allocated memory?

You detect it by not using it. It's your code, and you are assumed to know what
you are doing. You are in control; you allocate the pointer variable, fill it
with a pointer to storage, and then subsequently dispose of the storage. You do
this explicitly. It behoves you, as a competent programmer to then /not/
dereference the pointer variable that you /know/ no longer points to storage.

Having said that, there are techniques that /you/ can employ that will permit
you to be lax in tracking whether or not pointer variables point at storage. One
such technique is to assign the pointer variable a NULL value whenever the
pointer no longer points to allocated storage. Something like

{
char *p = NULL;

p = malloc(1);

free(p); p = NULL;
}

With this, a simple test before dereferencing will suffice...

if (p) *p = 100;
I'm sure you can come up with other methods of protecting yourself when you are
less than thorough in your handling of pointer variables.

- --
Lew Pitcher
IT Specialist, Enterprise Data Systems,
Enterprise Technology Solutions, TD Bank Financial Group

(Opinions expressed are my own, not my employers')
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (MingW32)

iD8DBQFDFvBFagV FX4UWr64RArtmAJ 9qCfsS65UXU74Pr +c7g7V41Xe5gQCe ONVE
j+dalVn2+yk0wJz mNDLnSuA=
=KwfF
-----END PGP SIGNATURE-----

[Rob]

Lew Pitcher wrote:

You detect it by not using it. It's your code, and you are assumed to know what
you are doing. You are in control; you allocate the pointer variable, fill it
with a pointer to storage, and then subsequently dispose of the storage. You do
this explicitly. It behoves you, as a competent programmer to then /not/
dereference the pointer variable that you /know/ no longer points to storage.

You are right. I asked the question because I was trying to implent
safety checks on functions and abort the program if it did something
illegal such as trying to access an illegal pointer. It seems this is
too much trouble, so I'll just go with the "be a competent programmer"
approach. :)

[David Resnick]

Rob wrote:

Lew Pitcher wrote:

You detect it by not using it. It's your code, and you are assumed to know what
you are doing. You are in control; you allocate the pointer variable, fill it
with a pointer to storage, and then subsequently dispose of the storage. You do
this explicitly. It behoves you, as a competent programmer to then /not/
dereference the pointer variable that you /know/ no longer points to storage.

You are right. I asked the question because I was trying to implent
safety checks on functions and abort the program if it did something
illegal such as trying to access an illegal pointer. It seems this is
too much trouble, so I'll just go with the "be a competent programmer"
approach. :)

But of course, you will make mistakes in a very large program...
There will be misunderstandin gs about who frees what, less than
competent programming somewhere, etc. It is nice
to have external tools to help diagnose such, as they often show
up in subtle ways. Tools vary with platform, and thus aren't on
topic here, but include stuff like purify/valgrind/electic
fence/mpatrol/
dmalloc/setting MALLOC_CHECK_=2/etc.

-David

[Gordon Burditt]

>int *p;

p = malloc(1);

free(p); p; /* possible smegmentation fault here */
/* */
In the above code, how do I detect that variable p points to nothing?
You can't even TRY: doing anything with the value of p invokes the
wrath of undefined behavior. You might try setting p to NULL
immediately after the free() call, but *DO NOT* assume that the
fact that it's not null means it points somewhere valid unless you
are sure you've coded it that way. Why? Code like:

destructor(p); /* free p and its associated buffers */

cannot set p to NULL in the calling function, assuming destructor()
is an actual function. More often, a function cannot set all of
the copies of the pointer it's freeing to NULL because it doesn't
now where the copies are.

In other words, how do I detect a freed memory pointer, as opposed to a
pointer that points to allocated memory?

Keep track of it yourself.

Gordon L. Burditt

[Keith Thompson]

"EventHelix.com " <ev********@gma il.com> writes:

There is no general way to do this.
To do what? Please provide context; don't assume that your readers
can easily see the parent article, or even the subject header.

If you want to post a followup via groups.google.c om, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

The parent article asked about how to detect, after a call to free(p),
that p is no longer a valid pointer. (Quick answer: you can't.)
One way is to write your own
wrappers around malloc and free and include different signatures in the
buffer that can be checked.

Microsoft Visual C++ compiler does something similar in a Debug build.
When a buffer is freed, it copies a known signature pattern in all the
bytes of the buffer.

It would also have to initialize newly malloc()ed memory with some
other pattern. Also, it can't easily handle cases like this:

p1 = malloc(SOME_SIZ E);
...
free(p1);
...
p2 = malloc(SOME_SIZ E);

After the second malloc(), p2 might very well point to the same chunk
of memory that p1 pointed to. p1 will appear to point to valid
memory; there's no good way to detect that this is merely accidental.

Tricks like writing 0xDEADBEEF into uninitialized memory can catch
some problems, but they can't catch everything.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.