[Bug 1091186] Re: Backport upstream bug 13844 - fix for futex issue

[Mark Rutland]

Originally, when we ran a 32bit mallocstress under a 64bit kernel on an
ARM fast model, mallocstress would deadlock (even with relatively small
numbers of threads and loops). Will Deacon looked into this, and saw
that all threads were waiting for the same futex. We believe the non-
atomic eglibc locking implementation issue was to blame for the threads
getting into this state.

I've installed the following packages dervived from the proposed eglibc (as described in http://launchpad.net/ubuntu/+source/eglibc/2.15-0ubuntu20.1) onto a quantal core image:
* libc-dev-bin
* libc6-dev
* libc-bin
* libc6
* multiarch-support

With these installed, I no longer experience deadlock in mallocstress.

I note the updated package contains another related bug fix:
https://bugs.launchpad.net/ubuntu/quantal/+source/eglibc/+bug/1081734,
which is supposed to fix this issue by changing the internal structure
of malloc/calloc. Due to this, I'm unable to say which change actually
fixes the issue.

I took the liberty to run a larger selection of LTP tests, and have not
experienced any regressions with the updated packages, so having both
doesn't seem to be harmful, at least.

-- 
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/1091186

Title:
  Backport upstream bug 13844 - fix for futex issue

Status in Embedded GLIBC:
  Fix Released
Status in “eglibc” package in Ubuntu:
  Fix Released
Status in “eglibc” source package in Precise:
  Fix Committed
Status in “eglibc” source package in Quantal:
  Fix Committed

Bug description:
  [Impact / Justification]
  There was a bug in glibc where custom lowlevellock implementations weren't being used, but rather the generic one was instead.  This was a non-issue on most arches, however hppa, ARM, and Sparc needed their own custom implementation to have sane futexes.  The patch from upstream fixes this by swapping a "" include for a <> include, which correctly walks sysdeps paths and grabs the arch-specific implementations.

  [Test Case]
  I don't personally have a good test for this, but there are several people very keen on having this fix in that will test quite heavily on my behalf, I'm told.  I'll make sure they do so (and bonus points if they document their testcase)...

  [Regression Potential]
  This patch has zero effect on i386, x86_64, and powerpc, and the architecture this does effect (armel/armhf) was quite fundamentally broken, apparently, so the only risk here is that it remains broken, which I'm told by people who've already tested, it won't.

  [Original Report]
  There is a subtle futex bug in glibc 2.15 which is fixed dealt with by BZ #13844 (http://sourceware.org/bugzilla/show_bug.cgi?id=13844).

  This is being hit regularly when testing locks on ARM.

  Can this be backported to precise and quantal (which I believe are
  both 2.15 based)?

  The patch is here:
  http://sourceware.org/git/?p=glibc.git;a=commit;h=7e7fa5f8719c0a497f4b262e6fb5625c13b6c22e

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