Bug#489906: glibc: tst-regex fails on hppa
Package: libc6 Version: 2.7-12 Severity: critical tst-regex fails on hppa, which IMHO is not something acceptable for a release architecture. -- System Information: Debian Release: lenny/sid APT prefers unstable APT policy: (500, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Versions of packages libc6 depends on: ii libgcc1 1:4.3.1-2 GCC support library libc6 recommends no packages. -- debconf information excluded -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489906: glibc: tst-regex fails on hppa
On Tue, Jul 8, 2008 at 12:21 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > Package: libc6 > Version: 2.7-12 > Severity: critical > > tst-regex fails on hppa, which IMHO is not something acceptable for a > release architecture. > > -- System Information: > Debian Release: lenny/sid > APT prefers unstable > APT policy: (500, 'unstable'), (1, 'experimental') > Architecture: amd64 (x86_64) > > Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) This is clearly not the machine or kernel tuple which the test is failing on? :-) What machine and kernel are you using? What provides the kernel headers? Do you have a recipe for building locally? e.g. # put unstable sources list in your /etc/apt/sources.list apt-get build-dep glibc apt-get source glibc dpkg-buildpackage -rfakeroot Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489906: glibc: tst-regex fails on hppa
Carlos O'Donell a écrit : > On Tue, Jul 8, 2008 at 12:21 PM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: >> Package: libc6 >> Version: 2.7-12 >> Severity: critical >> >> tst-regex fails on hppa, which IMHO is not something acceptable for a >> release architecture. >> >> -- System Information: >> Debian Release: lenny/sid >> APT prefers unstable >> APT policy: (500, 'unstable'), (1, 'experimental') >> Architecture: amd64 (x86_64) >> >> Kernel: Linux 2.6.25-2-amd64 (SMP w/2 CPU cores) > > This is clearly not the machine or kernel tuple which the test is > failing on? :-) Oops sorry, I did everything to quick in the last few days... > What machine and kernel are you using? I am using one of the machines from the esiee cluster: Linux magnum 2.6.22.14 #1 SMP Tue Nov 27 12:00:31 CET 2007 parisc64 GNU/Linux 4 PA8800 (Mako) CPUs > What provides the kernel headers? linux-libc-dev After a few more tests, I am not that sure it comes from there. It looks like the 3 failed / 3 successful build I had were not statistically enough. I'll work again on that problem at the beginning of next week. > Do you have a recipe for building locally? > > e.g. > # put unstable sources list in your /etc/apt/sources.list > apt-get build-dep glibc > apt-get source glibc > dpkg-buildpackage -rfakeroot > Yes, that's exactly what I am using. -- .''`. 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#489906: glibc: tst-regex fails on hppa
Hi,
For those that are not on IRC, I have made a lot of progress on this
bug. The problem comes from the patch any/cvs-strerror_r.diff. However,
this patch looks ok, actually comes from upstream and fix a bug. It
seems it only triggers a lock bug on hppa.
FYI you will find below the part of the patch that causes the problem in
case of tst-regex. It's only a change in the locks type.
Cheers,
Aurelien
--- glibc-2.7.orig/locale/setlocale.c
+++ glibc-2.7/locale/setlocale.c
@@ -123,7 +123,7 @@
/* Lock for protecting global data. */
-__libc_lock_define_initialized (, __libc_setlocale_lock attribute_hidden)
+__libc_rwlock_define_initialized (, __libc_setlocale_lock attribute_hidden)
/* Defined in loadmsgcat.c. */
extern int _nl_msg_cat_cntr;
@@ -314,7 +314,7 @@
}
/* Protect global data. */
- __libc_lock_lock (__libc_setlocale_lock);
+ __libc_rwlock_wrlock (__libc_setlocale_lock);
/* Load the new data for each category. */
while (category-- > 0)
@@ -381,7 +381,7 @@
free ((char *) newnames[category]);
/* Critical section left. */
- __libc_lock_unlock (__libc_setlocale_lock);
+ __libc_rwlock_unlock (__libc_setlocale_lock);
/* Free the resources (the locale path variable). */
free (locale_path);
@@ -394,7 +394,7 @@
const char *newname[1] = { locale };
/* Protect global data. */
- __libc_lock_lock (__libc_setlocale_lock);
+ __libc_rwlock_wrlock (__libc_setlocale_lock);
if (CATEGORY_USED (category))
{
@@ -446,7 +446,7 @@
}
/* Critical section left. */
- __libc_lock_unlock (__libc_setlocale_lock);
+ __libc_rwlock_unlock (__libc_setlocale_lock);
/* Free the resources (the locale path variable. */
free (locale_path);
--
.''`. 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#489906: glibc: tst-regex fails on hppa
__libc_setlocale_lock is defined differently on different places, it have been changed into rwlock in intl and locale subdirs, but it remains plain lock in time/alt_digit.c time/era.c wcsmbs/wcsmbsload.c Also the order of unlocking is not reverse order of locking order w.r.t __libc_setlocale_lock and nl_state. So it might help to move __libc_rwlock_rdlock(__libc_setlocale_lock) after __libc_rwlock_rdlock(_nl_state_lock) in intl/dcigettext.c and transform remaining __libc_setlocale_lock into rwlock. But none of these bugs should be hppa specific. Petr -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489906: glibc: tst-regex fails on hppa
There are already some related commits in upstream CVS.
Other posibility might be to just use attached patch instead
of cvs-strerror_r.diff
Petr
http://sourceware.org/ml/glibc-cvs/2008-q2/msg00089.html
2008-04-11 Jakub Jelinek <[EMAIL PROTECTED]>
[BZ #5443]
* time/era.c: Transform __libc_setlocale_lock into rwlock.
* time/alt_digit.c: Likewise.
* wcsmbs/wcsmbsload.c: Likewise.
http://sourceware.org/ml/glibc-cvs/2008-q3/msg00043.html
http://sourceware.org/ml/glibc-cvs/2008-q3/msg00045.html
2008-07-20 Ulrich Drepper <[EMAIL PROTECTED]>
* locale/setlocale.c (setname): Remove inline to avoid compiler
warning.
[BZ #6712]
* locale/setlocale.c (setlocale): Take the setlocale lock earlier.
--- intl/dcigettext.c.ORIG 2008-07-28 13:24:48.0 +
+++ intl/dcigettext.c 2008-07-28 13:26:18.0 +
@@ -445,6 +445,10 @@
#endif
__libc_rwlock_rdlock (_nl_state_lock);
+#ifdef _LIBC
+ __libc_lock_define (extern, __libc_setlocale_lock attribute_hidden)
+ __libc_lock_lock (__libc_setlocale_lock);
+#endif
/* If DOMAINNAME is NULL, we are interested in the default domain. If
CATEGORY is not LC_MESSAGES this might not make much sense but the
@@ -464,7 +468,7 @@
search->category = category;
# ifdef HAVE_PER_THREAD_LOCALE
# ifdef _LIBC
- localename = __current_locale_name (category);
+ localename = strdupa (__current_locale_name (category));
# endif
search->localename = localename;
# endif
@@ -488,6 +492,9 @@
else
retval = (char *) (*foundp)->translation;
+# ifdef _LIBC
+ __libc_lock_unlock (__libc_setlocale_lock);
+# endif
__libc_rwlock_unlock (_nl_state_lock);
return retval;
}
@@ -547,6 +554,7 @@
/* We cannot get the current working directory. Don't signal an
error but simply return the default string. */
FREE_BLOCKS (block_list);
+ __libc_lock_unlock (__libc_setlocale_lock);
__libc_rwlock_unlock (_nl_state_lock);
__set_errno (saved_errno);
return (plural == 0
@@ -613,6 +621,7 @@
{
no_translation:
FREE_BLOCKS (block_list);
+ __libc_lock_unlock (__libc_setlocale_lock);
__libc_rwlock_unlock (_nl_state_lock);
__set_errno (saved_errno);
return (plural == 0
@@ -723,6 +732,7 @@
if (plural)
retval = plural_lookup (domain, n, retval, retlen);
+ __libc_lock_unlock (__libc_setlocale_lock);
__libc_rwlock_unlock (_nl_state_lock);
return retval;
}
Bug#489906: glibc: tst-regex fails on hppa
On lun, jui 28, 2008 at 09:28:09 +, Petr Salinger wrote: > > __libc_setlocale_lock is defined differently on different places, > it have been changed into rwlock in intl and locale subdirs, > but it remains plain lock in > > time/alt_digit.c > time/era.c > wcsmbs/wcsmbsload.c > > Also the order of unlocking is not reverse order of locking order > w.r.t __libc_setlocale_lock and nl_state. > > So it might help to move __libc_rwlock_rdlock(__libc_setlocale_lock) > after __libc_rwlock_rdlock(_nl_state_lock) in intl/dcigettext.c > and transform remaining __libc_setlocale_lock into rwlock. > > But none of these bugs should be hppa specific. Well I'm not surprised, hppa is one of the sole architecture still using linuxthreads, and probably rwlock/mutexes are different enough so that seeing one of them like the other makes odd things, whereas NPTL has some kind of overlapping semantics on both that if it doesn't do the right thing, doesn't break mutexes too much ;) (I'm just guessing the the overlapping bits, but I really mean that hppa *is* different wrt locking). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpuZOwXG3amN.pgp Description: PGP signature
Bug#489906: glibc: tst-regex fails on hppa
On Tue, Jul 22, 2008 at 4:00 AM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > For those that are not on IRC, I have made a lot of progress on this > bug. The problem comes from the patch any/cvs-strerror_r.diff. However, > this patch looks ok, actually comes from upstream and fix a bug. It > seems it only triggers a lock bug on hppa. > > FYI you will find below the part of the patch that causes the problem in > case of tst-regex. It's only a change in the locks type. The only think I can think of is a miscompilation. If you turn down the optimization to -O1 on that file, does it help? Cheers, Carlos. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#489906: glibc: tst-regex fails on hppa
On Thu, Aug 07, 2008 at 10:27:45AM -0400, Carlos O'Donell wrote: > On Tue, Jul 22, 2008 at 4:00 AM, Aurelien Jarno <[EMAIL PROTECTED]> wrote: > > For those that are not on IRC, I have made a lot of progress on this > > bug. The problem comes from the patch any/cvs-strerror_r.diff. However, > > this patch looks ok, actually comes from upstream and fix a bug. It > > seems it only triggers a lock bug on hppa. > > > > FYI you will find below the part of the patch that causes the problem in > > case of tst-regex. It's only a change in the locks type. > > The only think I can think of is a miscompilation. If you turn down > the optimization to -O1 on that file, does it help? > We have actually solved this bug using a patch from upstream CVS: http://lists.debian.org/debian-glibc/2008/07/msg00240.html -- .''`. 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]
