Thread: malloc/free mark

  1. #1
    Registered User
    Join Date
    Nov 2008
    Location
    Cumaná, Venezuela
    Posts
    4

    malloc/free mark

    Hi ppl.
    suppose:
    Code:
    #include <stdlib.h>
    
    #define N 10
    int main(int argc, char *argv[])
    {
         int *p, n = N;
         p =  malloc( sizeof( int )*n );
         free( p );
         return 0;
    }
    How does malloc "mark" the place after the last element for allocating memory?
    How does free( p ) know what to free?
    Thanks


    P.S.: forgive my poor english please.

  2. #2
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    malloc normally doesn't put anything AFTER your allocated memory. It's not forbidden to do that, but there's also no requirement to do it.
    Normally, it has a small amount of data (8-32 bytes) in the memory just before (lower address) than the memory it returns for you to use. This data contains for example the size or the end of the memory allocated.

    Free knows how much memory immediately before the memory you got back that the extra data is, so it can "move back" to the actual position that this memory is at.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  3. #3
    Registered User
    Join Date
    Nov 2008
    Location
    Cumaná, Venezuela
    Posts
    4

    Thanks

    Thanks Mats.
    I am traying to induce a segmentation fault by modifying values using
    Code:
    p[k] = v;
    Is it possible? Which values should I use for k and v?
    Juan Carlos.

  4. #4
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    Well v doesn't matter, and any k outside the range of 0 to N-1 is dangerous.
    But there is no specific value of k which would guarantee a segfault.
    Nor any guarantee that having found a value for k, that it would always work.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  5. #5
    Registered User
    Join Date
    Nov 2008
    Location
    Cumaná, Venezuela
    Posts
    4

    Experiments

    I have done some experiments. I have used Debian GNU/linux gcc (32 and 64 bits). The values of p[k] (k = -1 and -2 for 32 and 64 bits respectively) depend on the value of n. And If I use several pointers *p, *q, *r,... the same values for p[k], q[k], r[k] are obtainded. When I modify these values before free(p),... I get the segmentation fault. Could it be the general rule?
    Juan Carlos

  6. #6
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    Quote Originally Posted by yosoyvenezolano View Post
    I have done some experiments. I have used Debian GNU/linux gcc (32 and 64 bits). The values of p[k] (k = -1 and -2 for 32 and 64 bits respectively) depend on the value of n. And If I use several pointers *p, *q, *r,... the same values for p[k], q[k], r[k] are obtainded. When I modify these values before free(p),... I get the segmentation fault. Could it be the general rule?
    Juan Carlos
    There is no general rule about how far you can go outside the bounds of what you've asked for from malloc before it will crash. You must not go outside the bound of what you've asked for - ever!
    It could do one thing one day, and something different the next, or next time you upgrade your compiler, or when you run it on another PC etc. It's undefined behaviour, and even do something bazaar like cause Calc to be launched*.

    * making fun of an unusual behaviour which some GCC users might have heard about in a certain version
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  7. #7
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    > Could it be the general rule?
    Or with
    gcc prog.c -lefence
    which adds a malloc debug library, then from
    p = malloc( sizeof( int )*n );
    anything like p[n] onwards will kill your program.

    But if you use extremely large values, you could well get lucky and find someone elses mapped memory, and then it work seem to "work".

    I'll say it again, there's nothing useful in this research.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  8. #8
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Like everyone else, there is no rule about what is kept outside of what you have allocated - it is fairly certain that negative offsets from the original pointer will cause problems, because in most implementations, that is where the administrative data is held for the allocation, so there may be pointers and other data that, if it's modified, causes problems for free or the next malloc. Areas above N-1 (where N is size in bytes) may well be completely unused if there aren't any more allocations, so you can write hundreds or thousands of bytes there - then you allocate more memory, and suddenly your overwrites are gone missing.


    However, this is just ONE possible scenario. malloc & free aren't necessarily implemented in the same way.

    And to repeat what was said earlier: Any access outside of the actually allocated space is guaranteed to be undefined behaviour. What actually happens will depend on the expected content. There is nothing useful to be gained from figuring out what happens if you overwrite bytes -1, -4, -16, -128 or n+16 etc.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  9. #9
    Registered User
    Join Date
    Nov 2008
    Location
    Cumaná, Venezuela
    Posts
    4

    Many thanks

    Many thanks to all you.
    I must say that I was lucky. I had a program chashing when (after a lot of times) free() was used. Based on one comment of mats
    Quote Originally Posted by matsp View Post
    Normally, it has a small amount of data (8-32 bytes) in the memory just before (lower address) than the memory it returns for you to use. This data contains for example the size or the end of the memory allocated. --
    Mats
    I Inspect the value of (say) p[k] (k=-1, -2 for 32, 64 bits implementation of gcc)
    And just before the crash this value had changed as consecuence of another asignation, say q[ l ] = vq. With this information then I fixed my program.
    I think that if the implementations of malloc() and free are known (the place for the administrative data are known) a tool for catching any unwished modification of that data could be designed.
    One last favor, could you please send me the output of
    Code:
    #include <stdio.h>
    #include <stdlib.h>
    #define N 100
    //K = -1 for 32 bits gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
    //K = -2 for 64 bits gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)
    #define K -1
    #define NL "\n"
    int main(int argc, char *argv[])
    {
    	int *p, n = N, k = K;
    	//int *q, *r;
    	int i;
    	for( i = 0; i < n; i++ )
    	{
    		p =  malloc( sizeof( int )*i );
    /*		q =  malloc( sizeof( int )*i );
    		r =  malloc( sizeof( int )*i );*/
    		printf("\n%i %i", i, p[k]) ;
    /*		printf("\n%i %i", i, q[k]) ;
    		printf("\n%i %i", i, r[k]) ;*/
    		free( p );
    /*		free( r );
    		free( s );*/
    	}
    	printf("%s", NL );
    	return 0;
    }
    with and without uncomenting the indicated lines.
    Thanks again.
    Juan Carlos.

  10. #10
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    But the implementation of malloc and free (along with the interpretation of the "admin data") is not the same for all architectures - it is not defined by any standard at all. If someone wishes to implement a malloc/free that doesn't store any data immediately before the block allocated, then that's perfectly valid and correct. [For example, we may store the admin data in a separate array].

    There is no value in knowing what is actually stored in a particular implementation.

    To catch bad memory accesses, there are other alternatives. Particularly useful is a "crumblezone" [that's my name for it, you may not find that in any computer dictionary] around the actual allocation. So you keep, say, 16 bytes of data on either side of the actual memory given to the applicatoon. This data is filled with a pattern that can be recognized later to see if it's been overwritten.

    You could implement that by using a macro to replace malloc and free:
    Code:
    #define malloc(x) myMalloc(x)
    #define free(x) myFree(x)
    void *myMalloc(size_t size);
    void myFree(void *ptr);
    and then implement myMalloc and myFree to allocate another 32 bytes and return a pointer 16 bytes into the memory.

    This is defined, because you have allocated the extra memory yourself, and you know it's content. Trying to do things with the memory that belongs to malloc and free is invalid and incorrect.

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

  11. #11
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,660
    A better approach would be to use tools like efence and valgrind to trap illegal memory accesses for you.

    A database (however comprehensive) of all your k[-1] tests will always be incomplete, and always subject to change at a moments notice.

    Change the OS / Compiler / standard library / compiler options - or anything else, and it could easily invalidate all your research.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.

  12. #12
    Kernel hacker
    Join Date
    Jul 2007
    Location
    Farncombe, Surrey, England
    Posts
    15,677
    Quote Originally Posted by Salem View Post
    A better approach would be to use tools like efence and valgrind to trap illegal memory accesses for you.

    A database (however comprehensive) of all your k[-1] tests will always be incomplete, and always subject to change at a moments notice.

    Change the OS / Compiler / standard library / compiler options - or anything else, and it could easily invalidate all your research.
    Or even, malloc may have something like this:
    Code:
    void *malloc(size_t size)
    {
        if (size > 102400) return big_malloc();
        else return small_malloc();
    }
    where the different options store different things in the admin block (and free knows from some magic part of the admin block whether it is a large or small block, for example a length of the actual block is stored at a fixed location back from the actual memory).

    --
    Mats
    Compilers can produce warnings - make the compiler programmers happy: Use them!
    Please don't PM me for help - and no, I don't do help over instant messengers.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. redirect malloc/free
    By pheres in forum C Programming
    Replies: 0
    Last Post: 03-21-2009, 03:28 AM
  2. labels inside the code #pragma mark label
    By nacho4d in forum C++ Programming
    Replies: 6
    Last Post: 01-11-2009, 02:50 AM
  3. Copying 2-d arrays
    By Holtzy in forum C++ Programming
    Replies: 11
    Last Post: 03-14-2008, 03:44 PM
  4. Student Mark Problem....(Array)
    By davidvoyage200 in forum C++ Programming
    Replies: 5
    Last Post: 12-02-2002, 06:37 PM
  5. try your heads on this
    By jasrajva in forum A Brief History of Cprogramming.com
    Replies: 70
    Last Post: 11-08-2001, 11:31 PM