Does malloc() reuse addresses?

[avasilev]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

 

[Dann Corbit]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc().

Yes. It happens all the time.

 

[Ben Pfaff]

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc().
Yes.

I would like to have confirmation on whether this is
practically a concern when pointers are used to uniquely
identify data structure instances - like in this example:

It's an incorrect approach. Strictly speaking the behavior of
doing anything with a pointer to freed memory yields undefined
behavior.

You're better off using a counter to stamp each new structure
with a unique serial number and then comparing those unique
serial numbers.

 

[goose]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc().

It might; you cannot depend on it though.

I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

yes

goose,

 

[Ancient_Hacker]

shouldnt be a problem, because if you're really keeping track of valid
pointers with that table, anytime you do a free() on a pointer you MUST
be removing that entry from the table.

 

[Barry Schwarz]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to

All in all a terrible plan.

Once an area of memory is freed, the pointer that was passed to free
becomes indeterminate so any attempt to evaluate that pointer invokes
undefined behavior.

Attempting to use the coincidence is extremely non-portable. Even if
the addresses should match up, how do you know that someone else did
not use (and free) the area in between the time you freed and
allocated it again. In a virtual memory system, even if the address
is the same it may be in a physically different portion of memory.
Some OSes reinitialize allocated memory (not necessarily to zero) as a
security precaution before allowing me to use it.


Remove del for email

 

[swengineer001]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

If you are doing what you say with the instance array, why are you not
removing the pointer from the array when you free the element of the
list. Sounds like you might want to rethink your design a little.

 

[Dann Corbit]

What (exactly) are you trying to accomplish? Maybe if we knew what it was,
we could offer a suitable and portable method of accomplishing it.

 

[avasilev]

shouldnt be a problem, because if you're really keeping track of valid
pointers with that table, anytime you do a free() on a pointer you MUST
be removing that entry from the table.

Yes, but later I can allocate a new pointer and add it to the table, it
could happen to have the same value. Then a previously non-vaid pointer
becomes valid now.

 

[Dann Corbit]

Yes, but later I can allocate a new pointer and add it to the table, it
could happen to have the same value. Then a previously non-vaid pointer
becomes valid now.

But it does not necessarily even point to the same kind of object.

Some other malloc(), even inside a library call or DLL or some such thing,
may have allocated memory at that starting address. And if it has not been
allocated even testing to see what the value is invokes undefined behavior.

We can say for sure:

Broken plan, don't do it.

Really, really. Don't.

 

[avasilev]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

Ok I will clarify this a bit, sice some people did not get it properly.
I have a list of instance pointers. Every allocated instance is added
to this list and every freed instance is immediately removed from
there. The problem is that copies of these pointers need to be passed
around, and it may happen that when such a copy has to be used, the
instance it points to may be already gone. So a way to validate the
pointer is needed - and this pointer comparison approach was chosen -
not by me, I am kindof revising the thing. So my question was to
confirm how reliable is the current verification mechanism. My opinion
is that it is not, since pointer values for different instances (in
time) may conicide.

 

[Dann Corbit]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

Ok I will clarify this a bit, sice some people did not get it properly.
I have a list of instance pointers. Every allocated instance is added
to this list and every freed instance is immediately removed from
there. The problem is that copies of these pointers need to be passed
around, and it may happen that when such a copy has to be used, the
instance it points to may be already gone. So a way to validate the
pointer is needed - and this pointer comparison approach was chosen -
not by me, I am kindof revising the thing. So my question was to
confirm how reliable is the current verification mechanism. My opinion
is that it is not, since pointer values for different instances (in
time) may conicide.

If you know for sure that:
1. The pointers in your list are valid pointers (all the bad ones, having
been removed)
2. The pointers in your list point to the appropriate data type

You still have a problem.

Suppose that pointer 0xdeadbeef is some valid "bucket of chicken" pointer in
your list. You assign that pointer to some struct in memory and say,
"Here's your bucket of chicken."
Later on, the pointer 0xdeadbeef gets freed. Now, we have this pointer,
0xdeadbeef and we want to know if it is valid. If we examine our "bucket of
chicken" pointer and say:
pointer 0 in the list is 0xc0ffc0ff. Is pointer 0xc0ffc0ff equal to pointer
0xdeadbeef?

The simple act of examining the contents of the pointer that is storing
0xdeadbeef invokes undefined behavior. Your computer could dump core, or
Scott Nudds could come flying out of your left nostril. Really, it's
practically in the standard. At least comp.std.c made a similar remark
concerning demons some time ago.

 

[avasilev]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

Ok I will clarify this a bit, sice some people did not get it properly.
I have a list of instance pointers. Every allocated instance is added
to this list and every freed instance is immediately removed from
there. The problem is that copies of these pointers need to be passed
around, and it may happen that when such a copy has to be used, the
instance it points to may be already gone. So a way to validate the
pointer is needed - and this pointer comparison approach was chosen -
not by me, I am kindof revising the thing. So my question was to
confirm how reliable is the current verification mechanism. My opinion
is that it is not, since pointer values for different instances (in
time) may conicide.

If you know for sure that:
1. The pointers in your list are valid pointers (all the bad ones, having
been removed)
2. The pointers in your list point to the appropriate data type

You still have a problem.

No no, Im no examining the moemory that hte pointer points to, I am
simply comparing the values of the pointers themselves, i.e. I am
comparing the addresses, not the contents of the memory that is pointed
to.

 

[avasilev]

Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

Ok I will clarify this a bit, sice some people did not get it properly.
I have a list of instance pointers. Every allocated instance is added
to this list and every freed instance is immediately removed from
there. The problem is that copies of these pointers need to be passed
around, and it may happen that when such a copy has to be used, the
instance it points to may be already gone. So a way to validate the
pointer is needed - and this pointer comparison approach was chosen -
not by me, I am kindof revising the thing. So my question was to
confirm how reliable is the current verification mechanism. My opinion
is that it is not, since pointer values for different instances (in
time) may conicide.

If you know for sure that:
1. The pointers in your list are valid pointers (all the bad ones, having
been removed)
2. The pointers in your list point to the appropriate data type

You still have a problem.

Suppose that pointer 0xdeadbeef is some valid "bucket of chicken" pointer in
your list. You assign that pointer to some struct in memory and say,
"Here's your bucket of chicken."
Later on, the pointer 0xdeadbeef gets freed. Now, we have this pointer,
0xdeadbeef and we want to know if it is valid. If we examine our "bucket of
chicken" pointer and say:
pointer 0 in the list is 0xc0ffc0ff. Is pointer 0xc0ffc0ff equal to pointer
0xdeadbeef?

The simple act of examining the contents of the pointer that is storing
0xdeadbeef invokes undefined behavior. Your computer could dump core, or
Scott Nudds could come flying out of your left nostril. Really, it's
practically in the standard. At least comp.std.c made a similar remark
concerning demons some time ago.

No no, Im no examining the moemory that hte pointer points to, I am
simply comparing the values of the pointers themselves, i.e. I am
comparing the addresses, not the contents of the memory that is pointed
to.

 

[Kenneth Brody]

avasilev wrote:
[...]

Ok I will clarify this a bit, sice some people did not get it properly.
I have a list of instance pointers. Every allocated instance is added
to this list and every freed instance is immediately removed from
there. The problem is that copies of these pointers need to be passed
around, and it may happen that when such a copy has to be used, the
instance it points to may be already gone. So a way to validate the
pointer is needed - and this pointer comparison approach was chosen -
not by me, I am kindof revising the thing. So my question was to
confirm how reliable is the current verification mechanism. My opinion
is that it is not, since pointer values for different instances (in
time) may conicide.

Well, I'm sure that many people will (rightly so) tell you that if
you free memory, that you should make sure that no pointers to it
will ever be used again.

Short of never free()ing any of your instances (a very bad idea),
or making sure to never reference a free()ed instance (a very good
idea), the only semi-bad solution I see would be to keep track of
all previously-allocated-but-now-freed addresses, and have your
allocate routine check if malloc returned one of them. If so,
keep malloc'ing until a non-previously-used address is returned,
and use that one. (And then free all of the "bad" ones, to keep
from having a memory leak.)

Of course, that "solution" just says "eww, yuck!" to me.

--
+-------------------------+--------------------+-----------------------+
| Kenneth J. Brody | www.hvcomputer.com | #include |
| kenbrody/at\spamcop.net | www.fptech.com | <std_disclaimer.h> |
+-------------------------+--------------------+-----------------------+
Don't e-mail me at: <mailto:[email protected]>

 

[Keith Thompson]

Dann Corbit wrote: [...]

The simple act of examining the contents of the pointer that is storing
0xdeadbeef invokes undefined behavior. Your computer could dump core, or
Scott Nudds could come flying out of your left nostril. Really, it's
practically in the standard. At least comp.std.c made a similar remark
concerning demons some time ago.

No no, Im no examining the moemory that hte pointer points to, I am
simply comparing the values of the pointers themselves, i.e. I am
comparing the addresses, not the contents of the memory that is pointed
to.

Understood, but just examining the pointer value itself, without
dereferencing it, invokes undefined behavior.

Concretely:

#include <stdio.h>
#include <stdlib.h>
int main(void)
{
void *ptr;
ptr = malloc(42);
printf("ptr = %p\n", ptr);
free(ptr);
printf("ptr = %p\n", ptr);
return 0;
}

The second printf call invokes UB (assuming the malloc() succeeded).

In real life, this is unlikely to cause any problems, but strictly
speaking a pointer to an object becomes indeterminate when the object
reaches the end of its lifetime.

 

[Dann Corbit]

[snip]

No no, Im no examining the moemory that hte pointer points to, I am
simply comparing the values of the pointers themselves, i.e. I am
comparing the addresses, not the contents of the memory that is pointed
to.

If p is an invalid pointer, then even:

p; /* Not much of a statement here. */

invokes undefined behavior.

 

[avasilev]

avasilev wrote:
Hi all,

my question is:

if i allocate some memory with malloc() and later free it (using
free()), is there a possibility that a consequent malloc() will
allocate memort at the same starting address and will return the same
pointer as the previous malloc(). I would like to have confirmation on
whether this is practically a concern when pointers are used to
uniquely identify data structure instances - like in this example:

int isInstanceValid(myStrict* inst)
{
int i;
for (i=0; i<instCount; ++i)
if (instances == inst)
return 1;

return 0;
}

In this example, if an instance is freed, and a pointer to it becomes
non-valid, and later a new structure is allocated in the list, the
function will return that the pointer is valid, although it is actually
not the instance that was originally referred.

Ok I will clarify this a bit, sice some people did not get it properly.
I have a list of instance pointers. Every allocated instance is added
to this list and every freed instance is immediately removed from
there. The problem is that copies of these pointers need to be passed
around, and it may happen that when such a copy has to be used, the
instance it points to may be already gone. So a way to validate the
pointer is needed - and this pointer comparison approach was chosen -
not by me, I am kindof revising the thing. So my question was to
confirm how reliable is the current verification mechanism. My opinion
is that it is not, since pointer values for different instances (in
time) may conicide.

If you know for sure that:
1. The pointers in your list are valid pointers (all the bad ones, having
been removed)
2. The pointers in your list point to the appropriate data type

You still have a problem.

Suppose that pointer 0xdeadbeef is some valid "bucket of chicken" pointer in
your list. You assign that pointer to some struct in memory and say,
"Here's your bucket of chicken."
Later on, the pointer 0xdeadbeef gets freed. Now, we have this pointer,
0xdeadbeef and we want to know if it is valid. If we examine our "bucket of
chicken" pointer and say:
pointer 0 in the list is 0xc0ffc0ff. Is pointer 0xc0ffc0ff equal to pointer
0xdeadbeef?

The simple act of examining the contents of the pointer that is storing
0xdeadbeef invokes undefined behavior. Your computer could dump core, or
Scott Nudds could come flying out of your left nostril. Really, it's
practically in the standard. At least comp.std.c made a similar remark
concerning demons some time ago.

No no, Im no examining the moemory that hte pointer points to, I am
simply comparing the values of the pointers themselves, i.e. I am
comparing the addresses, not the contents of the memory that is pointed
to.

Here is another example:

//this is how we add an instance
struct myStruct* newInst()
{
myStruct* inst = (myStruct*) malloc(sizeof myStruct);

//add the new instance to the linked list of instances
inst->next = instList;
instList = inst;
return inst;
}

//this is how we free an instance and remove it form the list
int delInst(myStruct* inst)
{
myStruct* cur = instList;
while (cur)
{
if (inst == cur)
{
/ /some code to remove from linked list goes here
free(cur);
return 1;
}
cur = cur->next;
}
return 0;
}

int isInstValid(myStruct* inst)
{
myStruct* cur = instList;
while (cur)
{
if (inst == cur) //here we compare the pointers themselves, not
touching hte memory they point to
return 1;
cur = cur->next;
}

return 0;
}


//and this is how we use this stuff

something = newInst();

....... a lot of code aexecuted here and possibly instance was deleted
from the list and freed

if (isInstValid(something))
doSomeStuffWithInstance(something);
else
//probably immediately set something to NULL


The problem is that even if 'if (isInstValid(something))' returns
true, the instance that 'something' points to may be not the original
one, but one that was allocated later, after the original one was
freed, both having hte same address by coincidence.

 

[Dann Corbit]

avasilev wrote:
[...]

Ok I will clarify this a bit, sice some people did not get it properly.
I have a list of instance pointers. Every allocated instance is added
to this list and every freed instance is immediately removed from
there. The problem is that copies of these pointers need to be passed
around, and it may happen that when such a copy has to be used, the
instance it points to may be already gone. So a way to validate the
pointer is needed - and this pointer comparison approach was chosen -
not by me, I am kindof revising the thing. So my question was to
confirm how reliable is the current verification mechanism. My opinion
is that it is not, since pointer values for different instances (in
time) may conicide.

Well, I'm sure that many people will (rightly so) tell you that if
you free memory, that you should make sure that no pointers to it
will ever be used again.

Short of never free()ing any of your instances (a very bad idea),
or making sure to never reference a free()ed instance (a very good
idea), the only semi-bad solution I see would be to keep track of
all previously-allocated-but-now-freed addresses, and have your
allocate routine check if malloc returned one of them. If so,
keep malloc'ing until a non-previously-used address is returned,
and use that one. (And then free all of the "bad" ones, to keep
from having a memory leak.)

Of course, that "solution" just says "eww, yuck!" to me.

It sounds a little to me like the data structure is upside down, or
disconnected.

Can the list of pointers to objects manage the links to external references?

I would like to know more about the problem. Why do the external objects
have pointers to a list of things that may disappear? What do they do with
the pointers? Why are the external objects not members of the structs in
the pointer list (e.g as a linked list or something).

I think that the tracking homework is strangely designed and I think that
good answers to the questions will depend on why these foreign objects have
addresses of potentially disappearing objects. Do multiple external items
point to the same list object address? What do they use this address for?

How can an external object from the list tell the difference between a
pointer to an object originally allocated to them verses a pointer to a
similar object (allocated with the same address) but allocated for a
different set of external objects?

 

[Dann Corbit]

Here is another example:

//this is how we add an instance
struct myStruct* newInst()
{
myStruct* inst = (myStruct*) malloc(sizeof myStruct);

//add the new instance to the linked list of instances
inst->next = instList;
instList = inst;
return inst;
}

//this is how we free an instance and remove it form the list
int delInst(myStruct* inst)
{
myStruct* cur = instList;
while (cur)
{
if (inst == cur)
{
/ /some code to remove from linked list goes here
free(cur);
return 1;
}
cur = cur->next;
}
return 0;
}

int isInstValid(myStruct* inst)
{
myStruct* cur = instList;
while (cur)
{
if (inst == cur) //here we compare the pointers themselves, not

This comparison invokes undefined behavior. It may not make your computer
dump core, but it could -- especially if you change compilers or move to
another platform.

touching hte memory they point to
return 1;
cur = cur->next;
}

return 0;
}


//and this is how we use this stuff

something = newInst();

...... a lot of code aexecuted here and possibly instance was deleted
from the list and freed

if (isInstValid(something))
doSomeStuffWithInstance(something);
else
//probably immediately set something to NULL


The problem is that even if 'if (isInstValid(something))' returns
true, the instance that 'something' points to may be not the original
one, but one that was allocated later, after the original one was
freed, both having hte same address by coincidence.

Yes, this is a real possibility.

What about a doubly linked list? Add a doubly linked list to the main data
structure, and use that list exclusively for creating objects that refer
back to the parent. The child objects can find their parents, and the
parent objects can find their children.