Re: Random failures when calling free()/malloc()

[Martin Schlemmer <azarah at gentoo dot org>]

On Sun, 2003-07-13 at 23:01, Martin Schlemmer wrote:
> On Sun, 2003-07-13 at 20:58, Ulrich Drepper wrote:
> 
> > I never suggested hardware failures.  And the older glibc can very well
> > produce a different memory layout which causes a memory corruption to be
> > not noticable.
> > 
> 
> Ok, I plugged a few holes, and if you look at:
> 
> ----------------------------
> #0  0x405ee1e1 in malloc_consolidate (av=0x406a37e0) at malloc.c:4355
> #1  0x405eda58 in _int_malloc (av=0x406a37e0, bytes=25) at malloc.c:3794
> #2  0x405ece0b in __libc_malloc (bytes=504) at malloc.c:3293
> #3  0x4053424e in g_malloc (n_bytes=504) at gmem.c:136
> ----------------------------
> 
> Where __libc_malloc() here is public_mALLOc(), it looks like
> __libc_malloc() (public_mALLOc()) is called as:
> 
>   __libc_malloc(504)
> 
> but then it ends up with the arg set to 25 which it uses to call
> __int_malloc()?  Beside some other checks added, I changed:
> 
> ----------------------------
> Void_t*
> public_mALLOc(size_t bytes)
> {
>   mstate ar_ptr;
>   Void_t *victim;
> 
>   __malloc_ptr_t (*hook) __MALLOC_P ((size_t, __const __malloc_ptr_t)) =
>     __malloc_hook;
>   if (hook != NULL)
>     return (*hook)(bytes, RETURN_ADDRESS (0));
> 
>   arena_get(ar_ptr, bytes);
>   if(!ar_ptr)
>     return 0;
>   victim = _int_malloc(ar_ptr, bytes);
>   if(!victim) {
> ----------------------------------
> 
> to:
> 
> ----------------------------------
> Void_t*
> public_mALLOc(size_t bytes)
> {
>   mstate ar_ptr;
>   Void_t *victim;
>   size_t tmp_bytes = bytes;
> 
>   __malloc_ptr_t (*hook) __MALLOC_P ((size_t, __const __malloc_ptr_t)) =
>     __malloc_hook;
>   if (hook != NULL)
>     return (*hook)(bytes, RETURN_ADDRESS (0));
> 
>   arena_get(ar_ptr, tmp_bytes);
>   if(!ar_ptr)
>     return 0;
>   victim = _int_malloc(ar_ptr, bytes);
>   if(!victim) {
> ------------------------------
> 
> in an attempt to ensure that arena_get() will not clobber
> 'bytes'.
> 
> Can this be some sort of issue with how args are passed to
> functions (gcc/kernel side) ?
> 
> I am not the greatest of debuggers, so a hand would be appreciated.
> 

The same seem to be evident for public_fREe().  Problem with how
arguments are passed to weak aliases?


Thanks,

-- 

Martin Schlemmer

Attachment: signature.asc
Description: This is a digitally signed message part