[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex->__data.__owner == 0' failed.



reassign 468793 glibc
forcemerge 479952 468793
thanks

On Mon, Nov 03, 2008 at 09:59:28AM +0000, 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

Wonderful, thanks a lot to him !

-- 
·O·  Pierre Habouzit
··O                                                madcoder@debian.org
OOO                                                http://www.madism.org

Attachment: pgp_VPmK4q5At.pgp
Description: PGP signature


Reply to: