Sharyathi Nagesh пишет:
> Hi Andrew
> While debugging I observed they are allocating memory block of size
> 1 and freeing it and the problem was noticed while doing that as the
> pointer is of type long.
>
> This problem is noticed only in thread context
we have data corruption and any actions may fail after it.
> and I am not noticing the same problem when I execute this test case
> ----------------------------------------------------
> #include<stdio.h>
>
> int main()
> {
> long int *ptr;
> ptr = malloc(1);
> free(ptr);
> printf("\n Success");
> }
> ----------------------------------------------------
you code is absolutely correct while hasn't access to this pointer.
#include <stdio.h>
int main()
{
long int *ptr;
ptr = malloc(1);
*ptr = 1;
free(ptr);
printf("\n Success");
}
==29690== Invalid write of size 4
==29690== at 0x8048447: main (in /home/shpagin/a.out)
==29690== Address 0x4177028 is 0 bytes inside a block of size 1 alloc'd
==29690== at 0x4022E88: malloc (in
/usr/lib/valgrind/x86-linux/vgpreload_memcheck.so)
==29690== by 0x8048440: main (in /home/shpagin/a.out)
>
> More over for me it looks like glibc issue when I tracked the
> glibc code the problem is noticed in this part of the code (glibc)
>
> free_check(){
> > ...........
> > (void)mutex_lock(&main_arena.mutex);
> > p = mem2chunk_check(mem, NULL); <== which is failing
>
> I was thinking should we change mem2chunk_chekc() to take care of this
> scenario ?
I don't understand what do you want handle in it.
>
> Will be eager to hear from you please let me know your thoughts
> Thanks
> Sharyathi
>
> [EMAIL PROTECTED] wrote:
>> Hi, All.
>>
>> Rishikesh K. Rajak wrote:
>>> On Wed, 2008-11-12 at 13:34 +0300, Andrew Vagin wrote:
>>>> Hi, All.
>>>>
>>>> Rishi, can you attach log from strace -f
>>>> ./testcases/kernel/mem/mtest07/mallocstress ?
>>>>
>>>
>>> Andrew, Sorry i could not expect this mail to go somewhere else.
>>> Attached is the strace output.
>> Thanks.
>> I found error for help valgrind.
>>
>> ==13393== Thread 56:
>> ==13393== Invalid write of size 8
>> ==13393== at 0x400C27: allocate_free (mallocstress.c:198)
>> ==13393== by 0x400E4D: alloc_mem (mallocstress.c:281)
>> ==13393== by 0x3B5F007299: start_thread (in /lib64/libpthread-2.8.so)
>> ==13393== by 0x3B5E4E439C: clone (in /lib64/libc-2.8.so)
>> ==13393== Address 0x4c36a60 is 0 bytes inside a block of size 1 alloc'd
>> ==13393== at 0x4A0739E: malloc (vg_replace_malloc.c:207)
>> ==13393== by 0x400BF0: allocate_free (mallocstress.c:192)
>> ==13393== by 0x400E4D: alloc_mem (mallocstress.c:281)
>> ==13393== by 0x3B5F007299: start_thread (in /lib64/libpthread-2.8.so)
>> ==13393== by 0x3B5E4E439C: clone (in /lib64/libc-2.8.so)
>>
>> (gdb) print i
>> $1 = 0
>> (gdb) print alloc_num
>> No symbol "alloc_num" in current context.
>> (gdb) print num_alloc
>> $2 = 0
>> (gdb) print size
>> $3 = 1
>>
>> strick the eye, we have pointer with type long, but allocate one byte
>> only.
>>
>> size_t size = 1;
>> long *ptrs[MAXPTRS];
>> ......
>> ptrs[num_alloc] = (long *)malloc(size);
>>
>> I use valgrind first time. Thanks for this possibility:).
>>
>> see the attached patch
>> test passed and valgrind don't report errors after my patch
>>
>> Thread [34]: allocate_free() returned 0, succeeded. Thread exiting.
>> main(): test passed.
>> ==13299==
>> ==13299== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 1)
>> ==13299== malloc/free: in use at exit: 0 bytes in 0 blocks.
>> ==13299== malloc/free: 233,080 allocs, 227,080 frees,
>> 5,454,975,665,283 bytes allocated.
>>
>>
>> ps: I use oldsize = 5, because long will be equal 8 in more case.
>> oldsize is previous value of fibannoci series
>>>
>>> - Rishi
>>>
>>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
