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]

chunk_free consolidate forward clarification ( was RE: malloc and threads)


Looks like there is a bug in the chunk_free code in glibc 2.2.2 at
line:3131.When consolidating forward,
I think the code is consolidating an in-use block by looking at the
next+nextsz block's in_use_bit.

If the blocks are in the order [IN-USE] [IN-USE] [FREE]. If I'm freeing the
first IN-USE block ,
consolidate forward is consolidating the second [IN-USE] block by looking at

the [FREE] block's in-use bit.

Does anyone know if this bug is already reported and fixed? 

Here is the code from glibc:2.2.2 , malloc.c

===============================================
if (!(hd & PREV_INUSE))                    /* consolidate backward */
  {
    prevsz = p->prev_size;
    p = chunk_at_offset(p, -(long)prevsz);
    sz += prevsz;

    if (p->fd == last_remainder(ar_ptr))     /* keep as last_remainder */
      islr = 1;
    else
      unlink(p, bck, fwd);
  }

  if (!(inuse_bit_at_offset(next, nextsz)))   /* consolidate forward */
  {
    sz += nextsz;

    if (!islr && next->fd == last_remainder(ar_ptr))
                                              /* re-insert last_remainder */
    {
      islr = 1;
      link_last_remainder(ar_ptr, p);
    }
    else
      unlink(next, bck, fwd);

    next = chunk_at_offset(p, sz);
  }
  else
    set_head(next, nextsz);                  /* clear inuse bit */
============================================================================

Thanks
_tisson

-----Original Message-----
From: Daniel Jacobowitz [mailto:drow@mvista.com] 
Sent: Sunday, December 01, 2002 9:10 AM
To: David Boreham
Cc: libc-alpha@sources.redhat.com
Subject: Re: malloc and threads


On Wed, Nov 27, 2002 at 09:07:58AM -0800, David Boreham wrote:
> > XScale is an ARM based processor 
> 
> Perhaps there is a bug in the XScale locking code
> or in the CPU hardware ?

Well, there are bugs in the ARM locking code.  I recommend interested
parties look at the conversation between myself and Richard Earnshaw
about this on the gcc-patches list, on Oct. 4th-7th:
  Subject: Atomic operations on the ARM

I don't believe it will affect malloc's use of locks; in short
test-and-set works but exchange-and-add is not atomic.

I'm not sure if compare_and_swap works correctly or not.  A glance
suggests that it does not.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer


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