On Wed, 2008-11-19 at 14:49 +0530, Sharyathi Nagesh wrote:
> 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
The patch is checked in.
Thanks Andrew for providing the patch.
Regards--
Subrata
> 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
-------------------------------------------------------------------------
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
