Processed (with 1 errors): Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
Processing commands for [EMAIL PROTECTED]: reassign 468793 glibc Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. Bug reassigned from package `tokyocabinet' to `glibc'. forcemerge 479952 468793 Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. Mismatch - only Bugs in the same package can be forcibly merged: Bug 468793 is not in the same package as 479952 thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Processed (with 1 errors): Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
Processing commands for [EMAIL PROTECTED]: reassign 468793 libc6/s390 Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. Warning: Unknown package 'libc6/s390' Bug reassigned from package `glibc' to `libc6/s390'. forcemerge 479952 468793 Bug#479952: libc6/s390 - __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed. Mismatch - only Bugs in the same package can be forcibly merged: Bug 468793 is not in the same package as 479952 thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Thu, 2008-10-30 at 14:12 +0100, Pierre Habouzit wrote: On Thu, Oct 30, 2008 at 12:44:35PM +, 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 [EMAIL PROTECTED], 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.0 +0200 +++ libc-s390/sysdeps/s390/bits/atomic.h2008-11-03 10:56:20.0 +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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
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 +, Martin Schwidefsky wrote: On Thu, 2008-10-30 at 14:12 +0100, Pierre Habouzit wrote: On Thu, Oct 30, 2008 at 12:44:35PM +, 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 [EMAIL PROTECTED], 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[EMAIL PROTECTED] OOOhttp://www.madism.org pgpTBKF1ygRKG.pgp Description: PGP signature
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 +, 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 [EMAIL PROTECTED], 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 `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Sun, Oct 19, 2008 at 04:48:26PM +0200, Pierre Habouzit wrote: Not that I'm aware of, and it's probably a bug in s390 assembly, and actually not a tokyocabinet bug _at all_. So unless upstream knows s390 assembly... I don't think he can help a lot :) For future reference, the hercules package contains an s390 emulator which might suffice for such things. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
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 [EMAIL PROTECTED], 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. -- blue skies, Martin. Reality continues to ruin my life. - Calvin. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
On Thu, Oct 30, 2008 at 12:44:35PM +, 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 [EMAIL PROTECTED], 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. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpJRvqW3lagJ.pgp Description: PGP signature
Bug#479952: Bug#468793: tokyocabinet - FTBFS: pthread_mutex_lock.c:71: __pthread_mutex_lock: Assertion `mutex-__data.__owner == 0' failed.
At 1225129482 time_t, Moritz Muehlenhoff wrote: Maybe we could forward this bug to Martin Schwidefsky [EMAIL PROTECTED], 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 Cheers, -- Julien Danjou .''`. Debian Developer : :' : http://julien.danjou.info `. `' http://people.debian.org/~acid `- 9A0D 5FD9 EB42 22F6 8974 C95C A462 B51E C2FE E5CD signature.asc Description: Digital signature
