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[i] == 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.
Jul 14 '06
48  5855 
"avasilev" <al********@gma il.comwrote in message
news:11******** *************@b 28g2000cwb.goog legroups.com...
[snip]
Hm, thats the strange thing here - the code is part of a widely used
open source cross-patform library, which supports a huge diversity of
compilers and platforms. And this code works on all... So, as you say
it seems that the problem with reading a pointer to free-d memory
should be theoretical. But it is really interesting that nobody has
complained so far about this.
What open source tool kit did the code come from?
Dann Corbit wrote:
"avasilev" <al********@gma il.comwrote in message
news:11******** *************@b 28g2000cwb.goog legroups.com...
[snip]
Hm, thats the strange thing here - the code is part of a widely used
open source cross-patform library, which supports a huge diversity of
compilers and platforms. And this code works on all... So, as you say
it seems that the problem with reading a pointer to free-d memory
should be theoretical. But it is really interesting that nobody has
complained so far about this.
What open source tool kit did the code come from?
iaxclient, in libiax2 - iax.c
This is the way sessions are handled.
"avasilev" <al********@gma il.comwrites:
Keith Thompson wrote:
>"avasilev" <al********@gma il.comwrites:
[...]
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
dereferencin g 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.
Hmm, ok this means that the compiler may try to do something "hidden"
with this pointer, i.e. try to dereference it somehow? At the assembly
level a pointer is just a register value which can be manupulated just
as any other value, as long as no attempts are made to dereference it.
So do you mean that the C standard states that accessing the value of a
pointer to a freed object causes undefined behaviour?
Yes, exactly.
For example, suppose the CPU has special address registers and the
ability to check whether a given address is either valid or null
(i.e., a null pointer is valid, a pointer to an existing object is
valid, and any other pointer is invalid). It makes sense to do this
check as early as possible, i.e., when the address is loaded into an
address register. The standard is designed to make such an
implementation legal.
When you pass a pointer to free(), you're promising that you're
finished with it. By examining the value of the pointer later on,
you're breaking that promise, and the implementation is free to strike
down upon thee with great vengeance and furious anger -- or, if it's
in a good mood, merely to crash your program.
(Note that you can examine the *representation * of any object by
treating it as an array of unsigned char, and it's been persuasively
argued that free() cannot change the representation of a pointer --
but I wouldn't necessarily suggest taking advantage of that.)
--
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.
>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.
If you keep freeing and reallocating chunks of memory, eventually
malloc() *MUST* either fail (return NULL) or return the same pointer
as it did before. Pointers have only a finite number of bits. If
pointers have 32 bits, you're guaranteed to have a repeat before
(2**32)+1 calls to malloc(), and possibly a lot sooner than that
if parts of the address space aren't used for dynamically allocated
memory.
Gordon L. Burditt
>Hmm, ok this means that the compiler may try to do something "hidden"
>with this pointer, i.e. try to dereference it somehow?
On a rather obscure processor which I'm sure nobody ever heard of,
the Intel Pentium, in protected mode, if you load an invalid segment
(hint: part of a pointer in large memory model) into a segment
register, you may get a trap which likely maps to some kind of
signal or program abort.
On the other hand, it's not that unreasonable for a compiler to
generate code to load a pointer it's about to use (maybe) into a
segment:offset register pair once early since reloading it repeatedly
is expensive.
The processor might also leave a pointer around in a segment register
from when it was valid (before free() got called), then try to save
and restore the segment registers with push/pop instructions, so
you can get traps at odd times when the pointer with the invalid
value isn't apparently being used.
>At the assembly
level a pointer is just a register value which can be manupulated just
as any other value, as long as no attempts are made to dereference it.
At the assembly level, you cannot put arbitrary bit patterns in the
segment registers without risking traps depending on the contents
of the corresponding segment table entry (which may well be changed
as the result of a malloc() or free() call). Get a manual on the
Intel Pentium and look it up. Oh, yes, the all-bits-zero segment
(a logical thing to use for NULL) is treated specially: it doesn't
cause a trap to load it in a segment register but it does if you
dereference it. It looks like Intel designed this with C (along
with other languages with null pointers) in mind.
>So do you mean that the C standard states that accessing the value of a
pointer to a freed object causes undefined behaviour?
Yes. Guess what? The undefined behavior that happens occurs at
the assembly-language level in this case.
Gordon L. Burditt
avasilev wrote:
>
The design is of an already written application (not by me) and I have
to live with it. I just want to eveluate what i can expect from this
approach. If I had to implement it, I would use unique ID-s.
This might be a Herculean task for an already-written application, but
if I were writing one from scratch, rather than this unique ID
nonsense, what I like to do is write custom free functions for various
structures, for instance i have widgets and any given widget might have
pointers pointing to it from thingies or from other widgets. I might
write something like
void free_widget( struct widget *w )
{
struct widget *w2;
struct thingy *t;
for ( w2 = first_widget; w2; w2 = w2->next )
if ( w2->widgetpointe r == w )
w2->widgetpointe r = NULL;
for (t = first_thingy; t; t = t->next )
if ( t->widgetpointe r == v )
t->widgetpointe r = NULL;
free( w );
return;
}
Of course this is a very simple example since in practice it'd be more
likely that (for instance) each thingy would contain an entire linked
list of pointers to various widgets, etc. But you get the idea.
Gordon Burditt wrote:
Hmm, ok this means that the compiler may try to do something "hidden"
with this pointer, i.e. try to dereference it somehow?
On a rather obscure processor which I'm sure nobody ever heard of,
the Intel Pentium, in protected mode, if you load an invalid segment
(hint: part of a pointer in large memory model) into a segment
register, you may get a trap which likely maps to some kind of
signal or program abort.
On the other hand, it's not that unreasonable for a compiler to
generate code to load a pointer it's about to use (maybe) into a
segment:offset register pair once early since reloading it repeatedly
is expensive.
The processor might also leave a pointer around in a segment register
from when it was valid (before free() got called), then try to save
and restore the segment registers with push/pop instructions, so
you can get traps at odd times when the pointer with the invalid
value isn't apparently being used.
At the assembly
level a pointer is just a register value which can be manupulated just
as any other value, as long as no attempts are made to dereference it.
At the assembly level, you cannot put arbitrary bit patterns in the
segment registers without risking traps depending on the contents
of the corresponding segment table entry (which may well be changed
as the result of a malloc() or free() call). Get a manual on the
Intel Pentium and look it up. Oh, yes, the all-bits-zero segment
(a logical thing to use for NULL) is treated specially: it doesn't
cause a trap to load it in a segment register but it does if you
dereference it. It looks like Intel designed this with C (along
with other languages with null pointers) in mind.
So do you mean that the C standard states that accessing the value of a
pointer to a freed object causes undefined behaviour?
Yes. Guess what? The undefined behavior that happens occurs at
the assembly-language level in this case.
And lest anyone think this is purely theoretical problem...
I know of a 16-bit compiler (not C) that passed the first few
parameters (of appropriate type) in registers, and the first two far
pointers were passed in es:di and ds:si (assuming those were
available). And yes, just passing a free'd pointer to a subroutine
would cause an abend.
OTOH, I don't know of any C compilers that did that. MS's 16 bit
register calling convention could pass near pointers in registers but
always passed far pointers on the stack.
Snis Pilbor wrote:
avasilev wrote:
The design is of an already written application (not by me) and I have
to live with it. I just want to eveluate what i can expect from this
approach. If I had to implement it, I would use unique ID-s.
This might be a Herculean task for an already-written application, but
if I were writing one from scratch, rather than this unique ID
nonsense, what I like to do is write custom free functions for various
structures, for instance i have widgets and any given widget might have
pointers pointing to it from thingies or from other widgets. I might
write something like
void free_widget( struct widget *w )
{
struct widget *w2;
struct thingy *t;
for ( w2 = first_widget; w2; w2 = w2->next )
if ( w2->widgetpointe r == w )
w2->widgetpointe r = NULL;
for (t = first_thingy; t; t = t->next )
if ( t->widgetpointe r == v )
t->widgetpointe r = NULL;
free( w );
return;
}
Of course this is a very simple example since in practice it'd be more
likely that (for instance) each thingy would contain an entire linked
list of pointers to various widgets, etc. But you get the idea.
I don't think this will help him. If he has multiple modules with a
pointer to an object and any one of them may free it at any time, with
a custom or non custom free, there is a design flaw that needs to be
fixed.
avasilev wrote:
Ancient_Hacker wrote:
>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.
And that's one of the reasons a function like you're trying to
implement is a rather futile approach.
Gordon Burditt wrote:
Hmm, ok this means that the compiler may try to do something "hidden"
with this pointer, i.e. try to dereference it somehow?
On a rather obscure processor which I'm sure nobody ever heard of,
the Intel Pentium, in protected mode, if you load an invalid segment
(hint: part of a pointer in large memory model) into a segment
register, you may get a trap which likely maps to some kind of
signal or program abort.
On the other hand, it's not that unreasonable for a compiler to
generate code to load a pointer it's about to use (maybe) into a
segment:offset register pair once early since reloading it repeatedly
is expensive.
The processor might also leave a pointer around in a segment register
from when it was valid (before free() got called), then try to save
and restore the segment registers with push/pop instructions, so
you can get traps at odd times when the pointer with the invalid
value isn't apparently being used.
At the assembly
level a pointer is just a register value which can be manupulated just
as any other value, as long as no attempts are made to dereference it.
At the assembly level, you cannot put arbitrary bit patterns in the
segment registers without risking traps depending on the contents
of the corresponding segment table entry (which may well be changed
as the result of a malloc() or free() call). Get a manual on the
Intel Pentium and look it up. Oh, yes, the all-bits-zero segment
(a logical thing to use for NULL) is treated specially: it doesn't
cause a trap to load it in a segment register but it does if you
dereference it. It looks like Intel designed this with C (along
with other languages with null pointers) in mind.
So do you mean that the C standard states that accessing the value of a
pointer to a freed object causes undefined behaviour?
Yes. Guess what? The undefined behavior that happens occurs at
the assembly-language level in this case.
Gordon L. Burditt
Ok, I got your point - segment registers. The thing is that this
approach that I am discussing ia actually used in a opensource cross
platform library. It runs on *nix, windows and macos. Nobody had
problems with this, ar at least nobody fixed this so far. My point is -
these OS-es do not use segmentation for the memory model of user-mode
processes. So you are right in theory, but in practice this does not
happen. Dont get me wrong, I dont defent this approach, I'm very far
from it - if I had to design it I would use handles. But it is already
done. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Chris Fogelklou |
last post by:
What is wrong with the above?
Don't worry, I already know (learned my lesson last week.) It is for the
benefit of our resident compiler guru who seems to think you need the cast.
I thought it too, up until I started posting here!
Thanks,
Chris
|
by: David Mathog |
last post by:
If this:
int i,sum;
int *array;
for(sum=0, i=0; i<len; i++){
sum += array;
}
is converted to this (never mind why for the moment):
|
by: Manu |
last post by:
Hello,
Can we say that the return addresses from the various malloc function
calls, in a program, will always be in a predefined order (increasing
or decreasing, depeding on how the heap is managed) ?
regards
Manu
|
by: jacob navia |
last post by:
In the C tutorial for lcc-win32, I have a small chapter
about a debugging implementation of malloc.
Here is the code, and the explanations that go with it.
I would appreciate your feedback both about the code and
the associated explanations.
---------------------------------------------------------------------
|
by: itsolution |
last post by:
Hi folks,
Could you shed some light on this issue?
my program is running on Freebsd as a daemon. When user sends a
request, it forks itself and lets its child process handles the
request.
And its main role is just to read a big xml file and save each object
into its embedded DB(such as gdbm).
| | |
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the choice of these technologies. I'm particularly interested in Zigbee because I've heard it does some...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| | |
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated we have to send another system
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
