r2786 - in glibc-package/trunk/debian: . patches patches/sh4
Author: aurel32 Date: 2008-01-19 12:24:08 + (Sat, 19 Jan 2008) New Revision: 2786 Added: glibc-package/trunk/debian/patches/sh4/cvs-nptl-private-futexes.diff Modified: glibc-package/trunk/debian/changelog glibc-package/trunk/debian/patches/series Log: * patches/sh4/cvs-nptl-private-futexes.diff: new patch from CVS to fix FTBFS on sh4. Modified: glibc-package/trunk/debian/changelog === --- glibc-package/trunk/debian/changelog2008-01-12 18:00:25 UTC (rev 2785) +++ glibc-package/trunk/debian/changelog2008-01-19 12:24:08 UTC (rev 2786) @@ -1,3 +1,11 @@ +glibc (2.7-7) unstable; urgency=low + + [ Arthur Loiret ] + * patches/sh4/cvs-nptl-private-futexes.diff: new patch from CVS to fix +FTBFS on sh4. + + -- Aurelien Jarno <[EMAIL PROTECTED]> Sat, 19 Jan 2008 12:01:23 +0100 + glibc (2.7-6) unstable; urgency=low [ Aurelien Jarno ] Modified: glibc-package/trunk/debian/patches/series === --- glibc-package/trunk/debian/patches/series 2008-01-12 18:00:25 UTC (rev 2785) +++ glibc-package/trunk/debian/patches/series 2008-01-19 12:24:08 UTC (rev 2786) @@ -110,6 +110,7 @@ powerpc/local-sysconf.diff sh4/local-fpscr_values.diff -p0 +sh4/cvs-nptl-private-futexes.diff -p0 sparc/local-fork.diff -p0 sparc/local-sparcv9-target.diff -p0 Added: glibc-package/trunk/debian/patches/sh4/cvs-nptl-private-futexes.diff === --- glibc-package/trunk/debian/patches/sh4/cvs-nptl-private-futexes.diff (rev 0) +++ glibc-package/trunk/debian/patches/sh4/cvs-nptl-private-futexes.diff 2008-01-19 12:24:08 UTC (rev 2786) @@ -0,0 +1,152 @@ +2007-12-04 Kaz Kojima <[EMAIL PROTECTED]> + + * sysdeps/unix/sysv/linux/sh/lowlevellock.S (__lll_timedlock_wait): + Store 2 before returning ETIMEDOUT. + +2007-11-03 Mike Frysinger <[EMAIL PROTECTED]> + + * sysdeps/unix/sysv/linux/sh/lowlevellock.S (LOAD_FUTEX_WAIT): Add + missing line continuations. + * sysdeps/unix/sysv/linux/sh/lowlevelrobustlock.S (LOAD_FUTEX_WAIT, + LOAD_FUTEX_WAKE): Likewise. Also add missing 3rd parameter + + +--- nptl/sysdeps/unix/sysv/linux/sh/lowlevellock.S 2007-08-03 15:44:15.0 + nptl/sysdeps/unix/sysv/linux/sh/lowlevellock.S 2007-12-05 02:31:10.0 + +@@ -76,7 +76,7 @@ + add tmp2, tmp ; \ + mov.l @tmp, tmp2 ; \ + bra 98f ; \ +- mov#FUTEX_PRIVATE_FLAG, tmp ++ mov#FUTEX_PRIVATE_FLAG, tmp ; \ + 99: .word PRIVATE_FUTEX - TLS_PRE_TCB_SIZE ; \ + 98: extu.b tmp, tmp; \ + xor tmp, reg; \ +@@ -88,7 +88,7 @@ + add tmp2, tmp ; \ + mov.l @tmp, tmp2 ; \ + bra 98f ; \ +- mov#FUTEX_PRIVATE_FLAG, tmp ++ mov#FUTEX_PRIVATE_FLAG, tmp ; \ + 99: .word PRIVATE_FUTEX - TLS_PRE_TCB_SIZE ; \ + 98: extu.b tmp, tmp; \ + xor tmp, reg; \ +@@ -96,13 +96,13 @@ + mov #FUTEX_WAIT, tmp ; \ + or tmp, reg + # endif +-# define LOAD_FUTEX_WAKE(reg,tmp) \ ++# define LOAD_FUTEX_WAKE(reg,tmp,tmp2) \ + stc gbr, tmp; \ + mov.w 99f, tmp2 ; \ + add tmp2, tmp ; \ + mov.l @tmp, tmp2 ; \ + bra 98f ; \ +- mov#FUTEX_PRIVATE_FLAG, tmp ++ mov#FUTEX_PRIVATE_FLAG, tmp ; \ + 99: .word PRIVATE_FUTEX - TLS_PRE_TCB_SIZE ; \ + 98: extu.b tmp, tmp; \ + xor tmp, reg; \ +@@ -225,6 +225,12 @@ + add #-8, r15 + cfi_adjust_cfa_offset(8) + ++ mov #2, r2 ++ XCHG (r2, @r8, r3) ++ ++ tst r3, r3 ++ bt 6f ++ + 1: + /* Get current time. */ + mov r15, r4 +@@ -250,17 +256,11 @@ + add #-1, r2 + 4: + cmp/pz r2 +- bf 5f /* Time is already up. */ ++ bf 2f /* Time is already up. */ + + mov.l r2, @r15/* Store relative timeout. */ + mov.l r3, @(4,r15) + +- mov #1, r3 +- mov #2, r4 +- CMPXCHG (r3, @r8, r4, r2) +- tst r2, r2 +- bt 8f +- + mov r8, r4 + mov r11, r5 + LOAD_FUTEX_WAIT (r5, r0, r1) +@@ -272,39 +272,29 @@ + SYSCALL_INST_PAD + mov r0, r5 + +-8: +- mov #0, r3 +- mov #2, r4 +- CMPXCHG (r3, @r8, r4, r2) +- bf/s7f +- mov#0, r0 ++ mov #2, r2 ++ XCHG (r2, @r8, r3) ++ ++ tst r3, r3 ++ bt/s6f ++ mov#-ETIMEDOUT, r1 ++ cmp/eq r5, r1 ++ bf 1b ++ ++2:mov #ETIMEDOUT, r3 + + 6: ++ mov r3, r0 + add #8, r15 + mov.l @r15+, r8 + mov.l @r15+, r9 + mov.l
Processing of glibc_2.3.6.ds1-13etch5_i386.changes
glibc_2.3.6.ds1-13etch5_i386.changes uploaded successfully to localhost along with the files: glibc_2.3.6.ds1-13etch5.dsc glibc_2.3.6.ds1-13etch5.diff.gz glibc-doc_2.3.6.ds1-13etch5_all.deb locales_2.3.6.ds1-13etch5_all.deb libc6_2.3.6.ds1-13etch5_i386.deb libc6-dev_2.3.6.ds1-13etch5_i386.deb libc6-prof_2.3.6.ds1-13etch5_i386.deb libc6-pic_2.3.6.ds1-13etch5_i386.deb locales-all_2.3.6.ds1-13etch5_i386.deb libc6-i686_2.3.6.ds1-13etch5_i386.deb libc6-xen_2.3.6.ds1-13etch5_i386.deb libc6-amd64_2.3.6.ds1-13etch5_i386.deb libc6-dev-amd64_2.3.6.ds1-13etch5_i386.deb nscd_2.3.6.ds1-13etch5_i386.deb libc6-dbg_2.3.6.ds1-13etch5_i386.deb libc6-udeb_2.3.6.ds1-13etch5_i386.udeb libnss-dns-udeb_2.3.6.ds1-13etch5_i386.udeb libnss-files-udeb_2.3.6.ds1-13etch5_i386.udeb Greetings, Your Debian queue daemon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#460226: Memory leak in SUNRPC code
On Fri, Jan 18, 2008 at 08:27:00PM +0100, Martin Zobel-Helas wrote: > Hi, > > On Sat Jan 12, 2008 at 13:41:12 +0100, Aurelien Jarno wrote: > > Hi release managers, > > > > On Fri, Jan 11, 2008 at 11:59:53AM +, Andre Cruz wrote: > > > Package: libc6 > > > Version: 2.3.6.ds1-13etch2 > > > Severity: serious > > > Tags: patch > > > > > > I've already submitted a patch upstream and it has been integrated. > > > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=5541 > > > > > > It should be backported to Etch. > > > > > > > Is it ok to upload a glibc package with this patch to *stable*? > > go ahead. > I have just uploaded it. -- .''`. 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#459322: libc6-dev: implementation of pthread_cleanup_pop_restore_np
One last attempt. I've copied the manpage exactly into the code. The
manpage says two example codes are "functionally equivalent" when
explaining what "pthread_cleanup_push_defer_np and
pthread_cleanup_pop_restore_np" do. If one uses one of the manpage
example codes, everything works in the testcase code I supplied. If one
uses the other of the manpage example example codes in the testcase code
I supplied, then the testcase code I supplied fails.
Summary:
---
The manpage (pthread_cleanup_pop_restore_np(3)
example code that fails is:
pthread_cleanup_push_defer_np(routine, arg);
pthread_cleanup_pop_defer_np(execute);
The manpage example code that works is:
{ int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldtype);
pthread_cleanup_push(routine, arg);
...
pthread_cleanup_pop(execute);
pthread_setcanceltype(oldtype, NULL);
}
Reasoning:
--
This is what the manpage says about them:
=
The following sequence
pthread_cleanup_push_defer_np(routine, arg);
pthread_cleanup_pop_defer_np(execute);
is functionally equivalent to (but more compact and more efficient
than)
{ int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldtype);
pthread_cleanup_push(routine, arg);
...
pthread_cleanup_pop(execute);
pthread_setcanceltype(oldtype, NULL);
}
=
Wel, the manpage is wrong. You choose where the bug is. But it's a bug.
Proof of claim:
--
The appended testcase code when compiled with
gcc -Wall -g -o testp-2 testp-2.c
will use the following sequence from the manpage
in its rather trivial thread function code, and fail as a result:
=
pthread_cleanup_push_defer_np (routine, arg);
// now back in deferred cancellation mode
err = pthread_mutex_lock (&mutex);
if (err)
print_error (err, "pthread_mutex_lock", __LINE__);
mcount++;
execute = !err;
// here we go back to async mode and THEN unlock, too late
pthread_cleanup_pop_restore_np (execute);
=
This exactly matches the manual page. You can see the two functions
that the manpage names:
pthread_cleanup_push_defer_np(routine, arg);
pthread_cleanup_pop_defer_np(execute);
at the beginning and end of the code sequence above (hey, the man page
is missing an ellipsis between the two lines!).
This is what happens when one runs the compliled code:
% ./testp-2
(3908) parent created thread OK
(3908) parent detached thread OK
(3908) parent sleeps 2s
(3909) child set async cancellation mode
(3909) child sleeps 1s
(3909) child wakes and starts cycling lock/unlock of mutex
(3908) parent wakes after sleep
(3908) parent starts sending cancels to child
(3908) parent spots child died
!!child died leaving lock set!!
1 threads created
1 cancel signals sent
2093121 lock cycles completed
The termination printout says that the thread function that was started
left a mutex locked after dying through receiving a cancel message. That
means it did not run the cleanup routine as it was supposed to.
On the other hand, if one compiles the test code with
gcc -Wall -DMY_DONT_USE_DEFER_NP -g -pthread testp-2.c -o testp-2
Then the code will use the alternative sequence from the manpage in
the interior of its thread function (and attention, that sequence
has another defect ... but one that is not exercised here; it
potentially can run a cleanup routine twice or more, but that depends on
implementation details within the pthread library). This code sequence is:
=
int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldtype);
pthread_cleanup_push(routine, arg);
// now back in deferred cancellation mode
err = pthread_mutex_lock (&mutex);
if (err)
print_error (err, "pthread_mutex_lock", __LINE__);
mcount++;
execute = !err;
pthread_cleanup_pop(execute);
pthread_setcanceltype(oldtype, NULL);
=
and once again you can see that it is exactly the manpage code
{ int oldtype;
pthread_setcanceltype(PTHREAD_CANCEL_DEFERRED, &oldtype);
pthread_cleanup_push(routine, arg);
...
pthread_cleanup_pop(execute);
pthread_setcanceltype(oldtype, NULL);
}
with the ellipsis replaced by those central 6 lines of code of mine
(which take a lock, print an error message if an error occurred, and
increment a count and then release
glibc override disparity
There are disparities between your recently accepted upload and the override file for the following file(s): libc6-amd64_2.3.6.ds1-13etch5_i386.deb: package says priority is standard, override says optional. Either the package or the override file is incorrect. If you think the override is correct and the package wrong please fix the package so that this disparity is fixed in the next upload. If you feel the override is incorrect then please reply to this mail and explain why. [NB: this is an automatically generated mail; if you replied to one like it before and have not received a response yet, please ignore this mail. Your reply needs to be processed by a human and will be in due course, but until then the installer will send these automated mails; sorry.] -- Debian distribution maintenance software (This message was generated automatically; if you believe that there is a problem with it please contact the archive administrators by mailing [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#461008: marked as done (locales: on install, perform locales generation in the background)
Your message dated Sat, 19 Jan 2008 20:17:43 +0200 with message-id <[EMAIL PROTECTED]> and subject line Bug#461008: locales: on install, perform locales generation in the background has caused the attached Bug report to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database) --- Begin Message --- Package: locales Version: 2.7-5 Severity: wishlist I have a dual AMD Opteron server on which I need to generate all the available locales (I cannot predict what each user needs). This takes a long time for each locales upgrade, during which some packages are in a half-installed state. Perhaps the locales generation could be performed in the background so that the rest of the installation could proceed? (I haven't given too much thought to the implications of this, so feel free to tell me it won't work :) Thanks, -- Fabian Fagerholm <[EMAIL PROTECTED]> --- End Message --- --- Begin Message --- On Wed, 2008-01-16 at 08:24 +0100, Aurelien Jarno wrote: > I don't think dpkg support this kind of thing. It should be possible to > background the process without telling dpkg, but that just means we > can't do any error handling. > > However, locales-all is probably the package you want to install. We could probably come up with all sorts of interesting solutions, but locales-all does seem to be best in this case. I guess you can always put locales on hold, upgrade everything else, and then upgrade locales separately. Or the other way around. Thanks for making me think some more about this. I'm closing the bug now. :) -- Fabian Fagerholm <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part --- End Message ---
