Hi Chris
Sorry for such a long gap. I tried finding out that why that test case was
failing by running a normal C program with malloc implementation.
I found that, when I am trying to allocate a smaller memory chunk, memory
is getting allocated from the same address, but for a larger memory chunk,
it is allocating from some different address i.e if condition is getting
true (that means that test is failing).
Couldn't figure out, why this difference. Any idea on to where should I
look into?
And yes, I will surely try to fix if this is a broken test. But moreover,
in some other kernel version it was passing. So, need to figure out as to
what changes has been made for this.
Thank you
Ritesh
On Thu, Sep 20, 2012 at 7:59 PM, <[email protected]> wrote:
> Hi!
> > Following are the lines of code where the test case is exiting, for
> kernel
> > 3.0.15 (ICS).
> >
> > 128 pm2=pm1;
> > 129 free(pm1);
> > 130
> > 131 if((pm1=(char *)calloc(memsize,1)) == NULL) {
> > 132 tst_resm(TFAIL, "calloc did not alloc memory ");
> > 133 tst_exit();
> > 134 }
> > 135
> > 136 if(pm1 != pm2) {
> > 137 tst_resm(TINFO, "pm1=%p pm2=%p ", pm1,pm2);
> > 138 tst_resm(TFAIL, "free did not dealloc memory ");
> > 139
> > tst_exit(); // *Here
> > code is exited in kernel 3.0.15 while it is passing in case of kernel 3.4
> > (ICS)*.
> > 140 }
> >
> >
> >
> > *LTP version = "LTP-20100630"*
> >
> > at line 136 my test is failing. Now isnt this condition of the dangling
> > pointer. At line 129 we are freeing pm1 this means that pm2 becomes a
> > dangling pointer.
> > And how come after doing
> > pm1=(char *)calloc(memsize,1)
> > pm1 is equal to pm2 for kernel 3.4 (ICS) (Since this test case is passing
> > for that)??
> >
> > According to me, it should not be equal.
>
> Indeed this test seems to be wrong. My guess is that it was written with
> 'it works so and so it must be true' attitude as it's not unlikely to
> get same pointer if you request chunk of a same size directly after you
> free one.
>
> So my conclusion is that the test is broken and should be fixed. Do you
> care to send a patch (against latest git tree)?
>
> --
> Cyril Hrubis
> [email protected]
>
------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
Ltp-list mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ltp-list
