Hei
Thanks for making my test case buggy ;)
Ya I was able to re-create the problem.
Subrata
When can we expect the patch provided by Andrew to be part of ltp
test suite
Thanks
Sharyathi
Andrew Vagin wrote:
> We found the reproducer. See the following examples.
>
> [EMAIL PROTECTED] ~ $ cat test.c
> #include <stdio.h>
> #include <stdlib.h>
> int main()
> {
> long *p;
> p = malloc(1);
> *p = ~0;
> free(p);
> }
> [EMAIL PROTECTED] ~ $ MALLOC_CHECK_=3 ./a.out
> malloc: using debugging hooks
> *** glibc detected *** ./a.out: free(): invalid pointer: 0x088aa008 ***
> ======= Backtrace: =========
> /lib/libc.so.6[0xb7fa53b6]
> /lib/libc.so.6(cfree+0x35)[0xb7fa6fd5]
> ./a.out[0x8048428]
> /lib/libc.so.6(__libc_start_main+0xe0)[0xb7f54400]
> ./a.out[0x8048371]
> ======= Memory map: ========
> 08048000-08049000 r-xp 00000000 08:02 361591 /home/shpagin/a.out
> 08049000-0804a000 r--p 00000000 08:02 361591 /home/shpagin/a.out
> 0804a000-0804b000 rw-p 00001000 08:02 361591 /home/shpagin/a.out
> 088aa000-088cb000 rw-p 088aa000 00:00 0 [heap]
> b7f31000-b7f3b000 r-xp 00000000 08:01 3290372
> /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
> b7f3b000-b7f3c000 r--p 00009000 08:01 3290372
> /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
> b7f3c000-b7f3d000 rw-p 0000a000 08:01 3290372
> /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1
> b7f3d000-b7f3e000 rw-p b7f3d000 00:00 0
> b7f3e000-b806d000 r-xp 00000000 08:01 3157103 /lib/libc-2.7.so
> b806d000-b806f000 r--p 0012e000 08:01 3157103 /lib/libc-2.7.so
> b806f000-b8070000 rw-p 00130000 08:01 3157103 /lib/libc-2.7.so
> b8070000-b8074000 rw-p b8070000 00:00 0
> b808d000-b808e000 r-xp b808d000 00:00 0 [vdso]
> b808e000-b80a8000 r-xp 00000000 08:01 3157085 /lib/ld-2.7.so
> b80a8000-b80a9000 r--p 0001a000 08:01 3157085 /lib/ld-2.7.so
> b80a9000-b80aa000 rw-p 0001b000 08:01 3157085 /lib/ld-2.7.so
> bfd95000-bfdaa000 rw-p bffeb000 00:00 0 [stack]
> Aborted.
>
> [EMAIL PROTECTED] ~ $ cat test.c
> #include <stdio.h>
> #include <stdlib.h>
> int main()
> {
> long *p;
> p = malloc(sizeof(long));
> *p = ~0;
> free(p);
> }
> [EMAIL PROTECTED] ~ $ MALLOC_CHECK_=3 ./a.out
> malloc: using debugging hooks
>
> from libc manual:
>
> When MALLOC_CHECK_ is set, a special (less efficient)
> implementation is used which is designed to be tolerant against simple
> errors, such as double calls of free with the same argument, or overruns
> of a single byte (off-by-one bugs).
>
> probably libc add guards before and after allocated memory and check it
> during operation "free".
>
> On Wed, Nov 19, 2008 at 10:48:20AM +0530, Sharyathi Nagesh wrote:
>> 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 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");
>> }
>> ----------------------------------------------------
>>
>> 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 ?
>>
>> 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
>
-------------------------------------------------------------------------
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
