Bug#468793: Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.
On Mon, Nov 03, 2008 at 10:59:28AM +0100, Martin Schwidefsky wrote:
> 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
>
I confirm that it works, thanks a lot!
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: