Detecting freed memory

Discussion in 'C Programming' started by Rob, Sep 1, 2005.

  1. Rob

    Rob Guest

    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?
    Rob, Sep 1, 2005
    #1
    1. Advertising

  2. 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
    EventHelix.com, Sep 1, 2005
    #2
    1. Advertising

  3. Rob

    Lew Pitcher Guest

    -----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)

    iD8DBQFDFvBFagVFX4UWr64RArtmAJ9qCfsS65UXU74Pr+c7g7V41Xe5gQCeONVE
    j+dalVn2+yk0wJzmNDLnSuA=
    =KwfF
    -----END PGP SIGNATURE-----
    Lew Pitcher, Sep 1, 2005
    #3
  4. Rob

    Rob Guest

    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. :)
    Rob, Sep 1, 2005
    #4
  5. 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 misunderstandings 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
    David Resnick, Sep 1, 2005
    #5
  6. >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
    Gordon Burditt, Sep 1, 2005
    #6
  7. "EventHelix.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.com, 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_SIZE);
    ...
    free(p1);
    ...
    p2 = malloc(SOME_SIZE);

    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_Keith) <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.
    Keith Thompson, Sep 1, 2005
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. jimjim
    Replies:
    28
    Views:
    873
    Michael Wojcik
    Apr 14, 2004
  2. ravi
    Replies:
    72
    Views:
    1,485
    RCollins
    Sep 14, 2004
  3. Replies:
    14
    Views:
    670
  4. MN
    Replies:
    32
    Views:
    940
    Richard Bos
    Mar 11, 2009
  5. Replies:
    5
    Views:
    554
    James Kuyper
    May 25, 2009
Loading...

Share This Page