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
