This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re:expected calloc out put
- From: Steven Munroe <munroesj at us dot ibm dot com>
- To: Sharyathi Nagesh <sharyath at in dot ibm dot com>, libc-alpha at sources dot redhat dot com
- Date: Wed, 25 Oct 2006 09:59:52 -0500
- Subject: Re:expected calloc out put
Sharyathi Nagesh <sharyath@in.ibm.com> writes:
> ltp test suite tests for 2 successive calloc()s like this
>=====================
>#include<stdio.h>
>#include<stdlib.h>
>#include<errno.h>
>#define MAX 8092*8092
>int main()
>{
> char *ptr1,*ptr2;
> ptr1=calloc(MAX,1);
> perror("calloc 1:");
> ptr2=ptr1;
> free(ptr1);
> perror("free ");
> ptr1=calloc(MAX,1);
> perror(" calloc 2");
> if(ptr1 == ptr2)
> printf("\n Success");
> else
> printf("\n Failure");
>}
>=====================
>fails in ppc 64 specifically. The test suite fails as ptr1 is not equal
>to ptr2. Is calloc() expected to return same values on successive
>allocation? as man page doesn't suggest any thing on this.
Your allocation is large enought to exceed the MMAP_THRESHOLD and use an
annonymous mmap for the storage. In this case the free is just an unmap
and the 2nd calloc is a new mmap. So it is the kernel choosing the address.
So what kernel and which distro are you running? RedHat? Fedora?
This might be execshield randomizing mmap addresses.