malloc/free in C

h/w · 02-13-2004, 12:26 PM

hey all. i was wondering why I dont get a segmentation fault or any kind of error running this:

Code:

#include <stdio.h>
#include <stdlib.h>

int main (void)
{
  int *p;
  p = (int *) malloc (sizeof (int));

  *p = 10;
  printf ("p contains %d and memloc is %p\n", *p, p);
  free (p);

  *p = 20;
  printf ("p contains %d and memloc is %p\n", *p, p);

  return 0;
}

i was expecting the call to free to lead to an error in the next reference to p. why does this work?
thanks once again.

infamous41md · 02-13-2004, 04:23 PM

malloc is responsible for maintaining the brk pointer for the process. this pointer points to the top of the heap(it grows up on linux). malloc obtains more heap space in PAGE_SIZE chunks, usually 0x1000. it then gives this memory to you when u call malloc. when you allocate more memory than malloc has left in its current chunk, it will move the brk pointer ahead by calling brk() to get another 0x1000 size chunk. when you free some memory, it doesnt necessarily mean that malloc will call brk() to shrink the heap. so, even tho u gave back the memory, it is still below the brk pointer so its still a valid reference. example:

Code:

#include <unistd.h>


int main()
{
    int y = 0;
    char    *x = NULL;


    x = malloc(100);
    if(!x)
        return 1;

    for(y = 0; y < 0x2000; y++)
        printf("x[%d] = %c \n", y, x[y]);
    

    return 0;
}

...
x[6838] =
x[6839] =
Segmentation fault

just showing you can way overstep your allocated memory as long as you stay below the brk pointer for the process. depending on how much you give back when you free, it may or may not actually move back the brk pointer.

h/w · 02-13-2004, 08:43 PM

thanks man.

h/w · 02-13-2004, 08:46 PM

ohhh, one more thing - how do we get the position offff this brk ptr? is the brk ptr the same as the stack ptr? or are they different things? (yeah, im a bit confused.)

llama_meme · 02-13-2004, 09:11 PM

You can't really, it's an implementation detail -- as far as the ANSI C standard is concerned, writing to memory which has been free'd always has the potential to cause the program to crash, and the behaviour will vary from OS to OS. The brk pointer isn't the same as the stack pointer, btw (the stack pointer is actually held in a processor register, it's part of the inner workings of x86 processors).

Alex

h/w · 02-13-2004, 11:00 PM

thanks guys.

infamous41md · 02-14-2004, 12:40 AM

man brk

sbrk increments the program's data space by increment
bytes. sbrk isn't a system call, it is just a C library
wrapper. Calling sbrk with an increment of 0 can be used
to find the current location of the program break.

cjcuk · 02-14-2004, 07:17 AM

As a piece of advice, following calls to free with a NULL assignment is not a bad thing to do. It is not foolproof, but can help you catch issues more easily.

eg:
free(ptr);
ptr = (type *)NULL;

h/w · 02-14-2004, 11:39 AM

gotcha!

h/w · 02-14-2004, 01:31 PM

Quote:

Originally posted by cjcuk
As a piece of advice, following calls to free with a NULL assignment is not a bad thing to do. It is not foolproof, but can help you catch issues more easily.

eg:
free(ptr);
ptr = (type *)NULL;

whenever i wrote a linked-list with structs, i would use free, and i never really checked to see if that memory was actually freed or not.

for some reason, im associating this behaviour more with native data types, than with objects i create, say with struct definitions.

h/w · 02-26-2004, 12:55 PM

just saw this snippet someplace:

Code:

void
f (void)
{
  struct sss *s = malloc (sizeof (*s));
  char *string2 = malloc (strlen (string1) + 1);

  /* ... */

  free (s);
  free (string2);
}

2 questions here - should malloc be called there with a sizeof(*s)? or should it be sizeof(struct sss)? wont what has been coded be allocating 4 bytes, and not the size of the struct?

also, is there supposed to be an order in which we free() the allocated mem? would reversing the two free() calls above make a difference?

thanks.

cjcuk · 02-26-2004, 01:11 PM

Quote:

Originally posted by h/w
just saw this snippet someplace:

Code:

void f (void) { struct sss *s = malloc (sizeof (*s)); char *string2 = malloc (strlen (string1) + 1); /* ... */ free (s); free (string2); }

2 questions here - should malloc be called there with a sizeof(*s)? or should it be sizeof(struct sss)? wont what has been coded be allocating 4 bytes, and not the size of the struct? [1]

also, is there supposed to be an order in which we free() the allocated mem? would reversing the two free() calls above make a difference? [2]

thanks.

[1] - No, *s is a dereferenced pointer, thus is considered the type it is pointing to. It is probably better to use sizeof(struct sss) -- as I am not sure if the compiler will always be successful in dealing with a dereferenced pointer in such a way ( though, it should be ).

[2] - No, reversing the calls is fine. Dynamic memory allocation does not work like the stack ( which is LIFO ), you can allocate and deallocate as and when necessary -- otherwise it would not be very dynamic

. The point behind malloc(3) is to try to speed up this process by using clever algorithms ( eg, doug lea's or phk's ) on how memory has been and will be ( predicted ) allocated.

h/w · 02-26-2004, 01:13 PM

cool - thanks. dont know what the heck i was thinking with question 1. d-oh!!