[Bug 1020210]

[Cvs-commit]

This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".

The branch, master has been updated
       via  abc26e998f74750850cc02f9c249ee794cbdd8e8 (commit)
       via  362b47fe09ca9a928d444c7e2f7992f7f61bfc3e (commit)
      from  b9bcbbcbe7afa94442d335811d4a1c1e0c0a1daf (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=abc26e998f74750850cc02f9c249ee794cbdd8e8

commit abc26e998f74750850cc02f9c249ee794cbdd8e8
Author: Maxim Kuvyrkov <maxim at kugelworks.com>
Date:   Tue Dec 24 09:55:03 2013 +1300

    Restore accidentally deleted bug-fix entries in NEWS.
    
    	* NEWS: Restore accidentally deleted bug-fix entries.

https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=362b47fe09ca9a928d444c7e2f7992f7f61bfc3e

commit 362b47fe09ca9a928d444c7e2f7992f7f61bfc3e
Author: Maxim Kuvyrkov <maxim at kugelworks.com>
Date:   Tue Dec 24 09:44:50 2013 +1300

    Fix race in free() of fastbin chunk: BZ #15073
    
    Perform sanity check only if we have_lock.  Due to lockless nature of fastbins
    we need to be careful derefencing pointers to fastbin entries (chunksize(old)
    in this case) in multithreaded environments.
    
    The fix is to add have_lock to the if-condition checks.  The rest of the patch
    only makes code more readable.
    
    	* malloc/malloc.c (_int_free): Perform sanity check only if we
    	have_lock.

-----------------------------------------------------------------------

Summary of changes:
 ChangeLog       |   11 +++++++++++
 NEWS            |   23 ++++++++++++-----------
 malloc/malloc.c |   20 ++++++++++++--------
 3 files changed, 35 insertions(+), 19 deletions(-)

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to eglibc in Ubuntu.
https://bugs.launchpad.net/bugs/1020210

Title:
  Race condition using ATOMIC_FASTBINS in _int_free causes crash or heap
  corruption

Status in Embedded GLIBC:
  Fix Released
Status in “eglibc” package in Ubuntu:
  Confirmed

Bug description:
  We have an application which makes heavy allocation and de-allocation
  demands from multiple threads.  We run this application continuously
  on many servers, and once every several CPU months or years, we were
  getting a crash in _int_free that did not look like vanilla heap
  corruption.  I believe I have narrowed it down to a race condition in
  _int_free due to the ATOMIC_FASTBINS feature.  Basically, in the
  lockless FASTBIN _int_free path, a chunk is pulled into a local
  variable with the intent to add it to the fastbins list.  However, the
  heap consolidation/trim code can race with this, and can coalesce the
  entire block and/or give it back to the OS before _int_free has a
  chance to try and store it into the fastbins list.

  The problem is very challenging to reproduce in situ, but using gdb I
  have a recipe which demonstrates the crash 100% of the time on my
  12.04 x64 system running eglibc 2.15.  It relies on malloc_trim,
  although in our in situ data, the consolidation is triggered as a
  result of a normal free.  malloc_trim is just easier to control.

  While I am not a glibc developer, I could not see any easy ways to fix
  the situation shy of disabling ATOMIC_FASTBINS.

  I am attaching the reproduction source.  Other pertinent information
  follows:

  > jpieper at calculon:~/downloads$ lsb_release -rd
  > Description:	Ubuntu 12.04 LTS
  > Release:	12.04

  > jpieper at calculon:~/downloads$ apt-cache policy libc6
  > libc6:
  >   Installed: 2.15-0ubuntu10
  >   Candidate: 2.15-0ubuntu10
  >   Version table:
  >  *** 2.15-0ubuntu10 0
  >        500 http://us.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
  >        100 /var/lib/dpkg/status

  What I expect: I expect the attached application, when run using the gdb script in the comments, to complete with no failures.
  What happened: A SIGSEGV after the final continue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/eglibc/+bug/1020210/+subscriptions