Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
- To: Pierre Habouzit <madcoder@debian.org>
- Cc: Julien Danjou <acid@debian.org>, Moritz Muehlenhoff <jmm@inutil.org>, 468793@bugs.debian.org, 479952@bugs.debian.org
- Subject: Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
- From: Martin Schwidefsky <schwidefsky@de.ibm.com>
- Date: Mon, 03 Nov 2008 10:59:28 +0100
- Message-id: <[🔎] 1225706368.24817.3.camel@localhost>
- Reply-to: schwidefsky@de.ibm.com, 479952@bugs.debian.org
- In-reply-to: <20081030131212.GA24098@artemis.corp>
- References: <20081010034000.62a66d18.henrich@debian.or.jp> <20081010075218.GA25048@artemis.corp> <20081018150900.GA3359@galadriel.inutil.org> <20081018155528.GB4803@artemis> <20081019161849.2f4964f8.henrich@debian.or.jp> <20081019144825.GA8719@artemis.corp> <20081027100119.GA593@abydos.adm.naquadah.org> <20081027174442.GA22885@inutil.org> <20081027185919.GA11317@abydos.adm.naquadah.org> <1225370675.6194.4.camel@skybook> <20081030131212.GA24098@artemis.corp>
On Thu, 2008-10-30 at 14:12 +0100, Pierre Habouzit wrote:
> On Thu, Oct 30, 2008 at 12:44:35PM +0000, Martin Schwidefsky wrote:
> > On Mon, 2008-10-27 at 19:59 +0100, Julien Danjou wrote:
> > > At 1225129482 time_t, Moritz Muehlenhoff wrote:
> > > > Maybe we could forward this bug to Martin Schwidefsky <schwidefsky@de.ibm.com>,
> > > > who is the glibc s390 maintainer and who works for IBM on the s390 Linux port.
> > >
> > > Why not.
> > >
> > > Martin, do you have any clue about bug #479952?
> > >
> > > http://bugs.debian.org/479952
> >
> > This does look familiar, I've seen this some years ago with broken
> > locking primivites in the nptl lowlevellock implementation. Could you
> > check your copy of glibc to verify if the locking inline assemblies in
> > nptl/sysdeps/unix/sysv/linux/s390/lowlevellock.h all have the "memory"
> > clobber? This has been the bug last time. Just for information I'm
> > currently on travel and will read my mail only randomly.
>
> They all have the memory constraint.
In the meantime Michael Matz from Novell found the problem: the
__lll_lock Funktion uses atomic_compare_and_exchange_bool_acq which uses
the __arch_compare_and_exchange_val_32_acq function which does NOT have
a "memory" clobber. The patch below should fix the problem
--
blue skies,
Martin.
"Reality continues to ruin my life." - Calvin.
---
diff -urpN libc/sysdeps/s390/bits/atomic.h libc-s390/sysdeps/s390/bits/atomic.h
--- libc/sysdeps/s390/bits/atomic.h 2003-05-05 20:20:54.000000000 +0200
+++ libc-s390/sysdeps/s390/bits/atomic.h 2008-11-03 10:56:20.000000000 +0100
@@ -56,7 +56,7 @@ typedef uintmax_t uatomic_max_t;
__typeof (*mem) __archold = (oldval); \
__asm __volatile ("cs %0,%2,%1" \
: "+d" (__archold), "=Q" (*__archmem) \
- : "d" (newval), "m" (*__archmem) : "cc" ); \
+ : "d" (newval), "m" (*__archmem) : "cc", "memory" ); \
__archold; })
#ifdef __s390x__
@@ -65,7 +65,8 @@ typedef uintmax_t uatomic_max_t;
__typeof (*mem) __archold = (oldval); \
__asm __volatile ("csg %0,%2,%1" \
: "+d" (__archold), "=Q" (*__archmem) \
- : "d" ((long) (newval)), "m" (*__archmem) : "cc" ); \
+ : "d" ((long) (newval)), "m" (*__archmem) \
+ : "cc", "memory" ); \
__archold; })
#else
/* For 31 bit we do not really need 64-bit compare-and-exchange. We can
Reply to: