Re: free'd address still readable?
From: Vinay Kurien (vinayik_at_charter.net)
Date: 04/07/04
- Next message: Grant Edwards: "Re: 64 bit or 32 bit"
- Previous message: Måns Rullgård: "Re: 64 bit or 32 bit"
- In reply to: Paul Pluzhnikov: "Re: free'd address still readable?"
- Next in thread: Floyd L. Davidson: "Re: free'd address still readable?"
- Reply: Floyd L. Davidson: "Re: free'd address still readable?"
- Reply: Juha Laiho: "Re: free'd address still readable?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 7 Apr 2004 09:09:02 -0500
"Paul Pluzhnikov" <ppluzhnikov-nsp@charter.net> wrote in message
news:m3isgcmj0j.fsf@salmon.parasoft.com...
> "Vinay Kurien" <vinayik@charter.net> writes:
>
> > In a process, if I allocate (using malloc()) an object I get an address.
I
> > am assuming this is a virtual address that the kernel maps to physical
> > memory. My question is, is that virtual address always 'readable' within
> > that process ?
>
> Not necessarily. While most malloc()s do not return any memory they
> obtained from the OS, the malloc in glibc does (under certain
> conditions). If you try to read such address, you'll get a SIGSEGV.
>
> > Even if that object is free'd ?
>
> If the object isn't free()d, the address will be valid.
> If it is, you can't assume anything.
But even if it is free'd, isn't that address just an index into somwhere
the available process heap ? Why is it not readable ? Is this behavior
dependant on the platform ?
I guess it comes down to something as simple as:
//Every time I allocate 'struct something' I set a unique key
struct something *a = (struct something*)malloc(10);
a->key = 0xAABBCCDD;
//Everytime I free 'struct something', I memset it.
free(a);
memset(a, 0, sizeof(struct something);
<snip>
if (a->key != 0xAABBCCDD) { //Is this legal ?
//object instance is free'd
return;
}
will this SIGSEGV ?
In my scenario the only difference is that I send the address in a, to
another
process, which that process echos back at a later time. At that later time,
all
I want to know is if that adress still stores an instance of 'struct
something' ... If not, I exit.
>
> > My issue is that, I pass around the context(virtual address) of that
object
> > to other processes and when the context is returned to the process that
> > allocated the object I am not sure if that object has been free'd or
not. Is
>
> Huh? You can't pass pointers to memory allocated in one process to
> another -- the address will not be valid in the other process.
I donot want the other process to try and dereference this memory. I just
want it to echo back the address to the process that allocated this object.
-Vinay
> > If I can read it, I can compare it to some unique number and know if
that
> > memory still holds an instance of the object.
>
> No, you can't: what if the first N bytes of that memory have not
> been touched, but the rest of it has been zero-ed out? Does it
> still hold your instance?
>
> Reading dangling memory results in undefined behavior; just don't
> do it.
>
> Cheers,
> --
> In order to understand recursion you must first understand recursion.
> Remove /-nsp/ for email.
- Next message: Grant Edwards: "Re: 64 bit or 32 bit"
- Previous message: Måns Rullgård: "Re: 64 bit or 32 bit"
- In reply to: Paul Pluzhnikov: "Re: free'd address still readable?"
- Next in thread: Floyd L. Davidson: "Re: free'd address still readable?"
- Reply: Floyd L. Davidson: "Re: free'd address still readable?"
- Reply: Juha Laiho: "Re: free'd address still readable?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
