This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Re:expected calloc out put
- From: Sharyathi Nagesh <sharyath at in dot ibm dot com>
- To: Steven Munroe <munroesj at us dot ibm dot com>
- Cc: sharyath at in dot ibm dot com, libc-alpha at sources dot redhat dot com
- Date: Thu, 26 Oct 2006 11:37:04 +0530
- Subject: Re: Re:expected calloc out put
- References: <453F7BE8.2070706@us.ibm.com>
- Reply-to: sharyath at in dot ibm dot com
I am using RHEL 5 Beta 1
kernel version 2.6.17-1.2519.4.21.el5
On Wed, 2006-10-25 at 09:59 -0500, Steven Munroe wrote:
> 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.
>
>