This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.


Thanks,

-- 

Martin Schlemmer
Gentoo Linux Developer, Desktop/System Team Developer
Cape Town, South Africa


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]