Bug#563882: (no subject)
This patch is already included in the Debian libc6 package. It actually may be the cause of the problem you reported. This problem is already fixed in 2.11.1 or master. Have you also applied the proper _second_ patch in that bug? C.f. my and H.J.Lu's comments and mailing list posts. Petr Pasky Baudis -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563882: (no subject)
On Wed, Jan 27, 2010 at 11:47:42AM +0100, Petr Baudis wrote: This patch is already included in the Debian libc6 package. It actually may be the cause of the problem you reported. This problem is already fixed in 2.11.1 or master. Have you also applied the proper _second_ patch in that bug? C.f. my and H.J.Lu's comments and mailing list posts. Here is the patch that is applied. It makes memchr.S identical to the current HEAD version. I guess the problem is *not* fixed in HEAD or 2.11.1. What is fixed is the stratcliff testsuite problem, and this fixes may have actually introduced this problem. 2009-11-18 H.J. Lu hongjiu...@intel.com [BZ #10162] * sysdeps/ia64/memchr.S: Don't use a simple loop on data shorter than software pipeline. Properly recover from shorter read. 2009-11-09 H.J. Lu hongjiu...@intel.com [BZ #10162] * sysdeps/ia64/memchr.S: Use a simple loop on data shorter than software pipeline. diff --git a/sysdeps/ia64/memchr.S b/sysdeps/ia64/memchr.S index cd062b2..cdd71ca 100644 --- a/sysdeps/ia64/memchr.S +++ b/sysdeps/ia64/memchr.S @@ -126,7 +126,16 @@ ENTRY(__memchr) br.ret.sptk.many b0 .recovery: - addsret0 = -((MEMLAT + 1) * 8), ret0;; +#if MEMLAT != 6 +# error MEMLAT must be 6! +#endif +(p[MEMLAT-6]) add ret0 = -8, ret0;; +(p[MEMLAT-5]) add ret0 = -8, ret0;; +(p[MEMLAT-4]) add ret0 = -8, ret0;; +(p[MEMLAT-3]) add ret0 = -8, ret0;; +(p[MEMLAT-2]) add ret0 = -8, ret0;; +(p[MEMLAT-1]) add ret0 = -8, ret0;; +(p[MEMLAT])add ret0 = -8, ret0;; (p[MEMLAT+1]) add ret0 = -8, ret0;; (p[MEMLAT+2]) add ret0 = -8, ret0;; .l4: -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Nuovo messaggio
Gentile Cliente, debian-glibc@lists.debian.org Il vostro servizio BancoPostaonline e scaduto. Dovete rinnovarlo subito altrimenti il vostro conto verra chiuso. Se volete usare questo servizio in futuro, dovete procedere subito. Per continuare, Il modulo di aggiornamento e`allegato a questa email. Scarica l'attaccamento, aprirlo e seguire le istruzioni sullo schermo. Registratevi con il vostro conto BancoPostaonline e seguite i passaggi necesari. Vi ringraziamo, La direzione Online Poste Italiane. BancoPostaonline_Forma.html Description: Binary data
Bug#566844: libc6 causing Authentication service cannot retrieve authentication info
On Mon, 25 Jan 2010, Aurelien Jarno wrote: On Mon, Jan 25, 2010 at 09:08:08AM -0500, root wrote: Package: libc6 Version: 2.7-18 Severity: critical Justification: breaks unrelated software I'm running Debian Lenny with a stock 2.6.26-2 AMD64 kernel, and after upgrading any of my systems to use the latest libc6 package from debian-security (2.7-18lenny2), all of my systems that use NIS can no longer authenticate. All I get is Authentication service cannot retrieve authentication info. If I upgrade a system to 2.7-18lenny2, I immediately start having problems, and as soon as I revert back to 2.7-18, everything works perfectly. I've been using the same NIS setup for close to 5 years now, and have been moving it along from Sarge, to Etch, to Lenny without any problems...until now. I am sorry about that. This security update was there to prevent leaking adjunct passwords to normal users. My /etc/nsswitch.conf: passwd: compat group: compat shadow: compat Like I said, I am using NIS, however both the NIS master server and the NIS clients both break when I upgrade libc6 to 2.7-18lenny2. The NIS server is again, a stock Debian Lenny server. With the NIS server, I am combining the passwd/shadow files on the NIS server into just the passwd map (using the MERGE_PASSWD option). So the NIS clients don't actually see any shadow file entries for any of the NIS accounts. Ok, so users were able to login even if there was no shadow entry. I've also tried changing the nsswitch.conf file to: passwd: nis files group: nis files shadow: files You'll notice I left the nis option off of the shadow entry, since there's no need for it, since there's no shadow map. My guess is that, this is the cause of the problem...In other words, because the system isn't seeing shadow entries, it's bailing out. But why all of a sudden did this break in the latest libc6? And is there a way to get the old functionality back? What the changes did is to stop merging adjunct passwords to the passwd database, and merge them in the shadow database instead. There is no new requirement for shadow entries. If you are not using adjunct password, no changes should have happened for you. As it doesn't work, it seems something has broken, we have to understand why. FYI, I have just done a NIS setup using the MERGE_PASSWD option, and only compat entries into /etc/nsswitch.conf, and I don't see this problem. I will need more informations to debug this: - Are you using adjunct passwords in addition to merged passwords? No. - As I understand, you have upgraded libc6 on both the NIS server and the clients. Can you please try to see if it also breaks if you upgrade only the clients? Yes it still breaks, when I upgrade just one of the clients. - Are you using nscd on the clients? No. - What the result of getent passwd a_nis_user on a client when running as a standard (local) user, a root user, for both Very interesting... Whether I run the getent command as root or a normal user, I get the following: On the libc6 (2.7-18) system: username:encrypted_passwd_here:123456:654321:MyName:/my/home/directory:/bin/tcsh On the libc6 (2.7-18lenny2) system: username:x:123456:654321:MyName:/my/home/directory:/bin/tcsh That does seem to be what is causing my problems... - Do you have more info the client system logs? Not really, the only thing I see is just: Jan 27 06:53:45 hostname su[31991]: pam_authenticate: Authentication service cannot retrieve authentication info Jan 27 06:53:45 hostname su[31991]: FAILED su for testuser2 by testuser1 Jan 27 06:53:45 hostname su[31991]: - pts/1 testuser1:testuser2 If you know of any way of getting more debug info from PAM, let me know and I'll run more tests. By the way, thank you for your help, I really appreciate it! -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#567116: reproducable segfault in printf / vfprintf
Subject: libc6: reproducable segfault in printf / vfprintf
Package: libc6
Version: 2.10.2-2
Justification: breaks the whole system
Severity: critical
after found a segfault problem in libc6 i have tried to construct a
minimal programm, that produce that error.
the following code produces this segfault. changing the last %5$s to
%1$s or removing one part, the segfaults disappear.
-
#include stdlib.h
#include stdio.h
int main(int argc, char **argv)
{
printf(%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%5$s
,,1, , , );
return 0;
}
-
compiled with gcc -g test.c (gcc-4.3.4-6)
-
ldd a.out
linux-vdso.so.1 = (0x7fffccd3d000)
libc.so.6 = /lib/libc.so.6 (0x7f216fcfc000)
/lib64/ld-linux-x86-64.so.2 (0x7f217006c000)
-
the check with valgrind :
-
==3488== Conditional jump or move depends on uninitialised value(s)
==3488==at 0x4E68595: vfprintf (vfprintf.c:1938)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
==3488== Uninitialised value was created by a stack allocation
==3488==at 0x4E68B9E: vfprintf (vfprintf.c:1710)
==3488==
==3488== Use of uninitialised value of size 8
==3488==at 0x4E6BBDE: vfprintf (vfprintf.c:1938)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
==3488== Uninitialised value was created by a stack allocation
==3488==at 0x4E68B9E: vfprintf (vfprintf.c:1710)
==3488==
==3488== Invalid read of size 4
==3488==at 0x4E6844D: vfprintf (vfprintf.c:1871)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
==3488== Address 0x7eeff9c20 is not stack'd, malloc'd or (recently) free'd
==3488==
==3488==
==3488== Process terminating with default action of signal 11 (SIGSEGV)
==3488== Access not within mapped region at address 0x7EEFF9C20
==3488==at 0x4E6844D: vfprintf (vfprintf.c:1871)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
-
i have verified that failure on various machines - clean squeeze
debootstrap chroot.
-- System Information:
Debian Release: 5.0.3
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32.5-thinkpad (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libc-bin 2.10.2-2 GNU C Library: Binaries
ii libgcc1 1:4.4.2-9 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.24 Debian configuration
management sy
pn glibc-doc none (no description available)
ii locales 2.10.2-2 GNU C Library: National
Language (
-- debconf information:
* glibc/upgrade: true
glibc/disable-screensaver:
glibc/restart-failed:
* glibc/restart-services: rsync cups cron
smime.p7s
Description: S/MIME Cryptographic Signature
Bug#567116: marked as done (reproducable segfault in printf / vfprintf)
Your message dated Wed, 27 Jan 2010 14:38:15 +0100
with message-id 20100127133815.ga21...@hall.aurel32.net
and subject line Re: Bug#567116: reproducable segfault in printf / vfprintf
has caused the Debian Bug report #567116,
regarding reproducable segfault in printf / vfprintf
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 this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
567116: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567116
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
---BeginMessage---
Subject: libc6: reproducable segfault in printf / vfprintf
Package: libc6
Version: 2.10.2-2
Justification: breaks the whole system
Severity: critical
after found a segfault problem in libc6 i have tried to construct a
minimal programm, that produce that error.
the following code produces this segfault. changing the last %5$s to
%1$s or removing one part, the segfaults disappear.
-
#include stdlib.h
#include stdio.h
int main(int argc, char **argv)
{
printf(%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%5$s
,,1, , , );
return 0;
}
-
compiled with gcc -g test.c (gcc-4.3.4-6)
-
ldd a.out
linux-vdso.so.1 = (0x7fffccd3d000)
libc.so.6 = /lib/libc.so.6 (0x7f216fcfc000)
/lib64/ld-linux-x86-64.so.2 (0x7f217006c000)
-
the check with valgrind :
-
==3488== Conditional jump or move depends on uninitialised value(s)
==3488==at 0x4E68595: vfprintf (vfprintf.c:1938)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
==3488== Uninitialised value was created by a stack allocation
==3488==at 0x4E68B9E: vfprintf (vfprintf.c:1710)
==3488==
==3488== Use of uninitialised value of size 8
==3488==at 0x4E6BBDE: vfprintf (vfprintf.c:1938)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
==3488== Uninitialised value was created by a stack allocation
==3488==at 0x4E68B9E: vfprintf (vfprintf.c:1710)
==3488==
==3488== Invalid read of size 4
==3488==at 0x4E6844D: vfprintf (vfprintf.c:1871)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
==3488== Address 0x7eeff9c20 is not stack'd, malloc'd or (recently) free'd
==3488==
==3488==
==3488== Process terminating with default action of signal 11 (SIGSEGV)
==3488== Access not within mapped region at address 0x7EEFF9C20
==3488==at 0x4E6844D: vfprintf (vfprintf.c:1871)
==3488==by 0x4E72599: printf (printf.c:35)
==3488==by 0x400524: main (test.c:89)
-
i have verified that failure on various machines - clean squeeze
debootstrap chroot.
-- System Information:
Debian Release: 5.0.3
APT prefers testing
APT policy: (500, 'testing'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.32.5-thinkpad (SMP w/2 CPU cores; PREEMPT)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Versions of packages libc6 depends on:
ii libc-bin 2.10.2-2 GNU C Library: Binaries
ii libgcc1 1:4.4.2-9 GCC support library
libc6 recommends no packages.
Versions of packages libc6 suggests:
ii debconf [debconf-2.0] 1.5.24 Debian configuration
management sy
pn glibc-doc none (no description available)
ii locales 2.10.2-2 GNU C Library: National
Language (
-- debconf information:
* glibc/upgrade: true
glibc/disable-screensaver:
glibc/restart-failed:
* glibc/restart-services: rsync cups cron
smime.p7s
Description: S/MIME Cryptographic Signature
---End Message---
---BeginMessage---
On Wed, Jan 27, 2010 at 01:28:42PM +0100, Manfred Benesch wrote:
Subject: libc6: reproducable segfault in printf / vfprintf
Package: libc6
Version: 2.10.2-2
Justification: breaks the whole system
Severity: critical
after found a segfault problem in libc6 i have tried to construct a
minimal programm, that produce that error.
the following code produces this segfault. changing the last %5$s to
%1$s or removing one part, the segfaults disappear.
Bug#567116: closed by Aurelien Jarno aurel...@aurel32.net (Re: Bug#567116: reproducable segfault in printf / vfprintf)
Of cours,
you're right - compiling without -Wall -W was a mistake on reducing the
real code to that minimal example. But correcting the sample code in the
following way, so the argument order is correct doesn't help :
-
#include stdlib.h
#include stdio.h
int main(int argc, char **argv)
{
printf(%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%2$i%3$s%4$s%5$s
,,1, , , );
return 0;
}
-
compile with : gcc -Wall -W -g -Os test.c - no warnings except unused argc/argv
tried with gcc-4.3 and gcc-4.4 - nothing helps
it doesn't matter where the references for argument 2-5 are, even if the order
is 1,2,3,4,5
changing all parameters to strings - same result
only removing at least one element works - why ?
valgrind - output looks like the one from first report
Debian Bug Tracking System schrieb:
This is an automatic notification regarding your Bug report
which was filed against the libc6 package:
#567116: reproducable segfault in printf / vfprintf
It has been closed by Aurelien Jarno aurel...@aurel32.net.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact Aurelien Jarno
aurel...@aurel32.net by
replying to this email.
Betreff:
Re: Bug#567116: reproducable segfault in printf / vfprintf
Von:
Aurelien Jarno aurel...@aurel32.net
Datum:
Wed, 27 Jan 2010 14:38:15 +0100
An:
Manfred Benesch manfred.bene...@inf.tu-dresden.de,
567116-d...@bugs.debian.org
An:
Manfred Benesch manfred.bene...@inf.tu-dresden.de,
567116-d...@bugs.debian.org
On Wed, Jan 27, 2010 at 01:28:42PM +0100, Manfred Benesch wrote:
Subject: libc6: reproducable segfault in printf / vfprintf
Package: libc6
Version: 2.10.2-2
Justification: breaks the whole system
Severity: critical
after found a segfault problem in libc6 i have tried to construct a
minimal programm, that produce that error.
the following code produces this segfault. changing the last %5$s to
%1$s or removing one part, the segfaults disappear.
-
#include stdlib.h
#include stdio.h
int main(int argc, char **argv)
{
printf(%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%5$s
,,1, , , );
return 0;
}
-
compiled with gcc -g test.c (gcc-4.3.4-6)
You forget compiling with -Wall. That will show you the problem is in
your code:
| test.c: In function ‘main’:
| test.c:7: warning: format argument 2 unused before used argument 5 in $-style
format
| test.c:7: warning: format argument 3 unused before used argument 5 in $-style
format
| test.c:7: warning: format argument 4 unused before used argument 5 in $-style
format
And quoting the standard:
| The format can contain either numbered argument conversion
| specifications (that is, %n$ and *m$), or unnumbered argument
| conversion specifications (that is, % and * ), but not both. The only
| exception to this is that %% can be mixed with the %n$ form. The
| results of mixing numbered and unnumbered argument specifications in a
| format string are undefined. When numbered argument specifications are
| used, specifying the Nth argument requires that all the leading
| arguments, from the first to the (N-1)th, are specified in the format
| string.
Closing the bug.
Betreff:
reproducable segfault in printf / vfprintf
Von:
Manfred Benesch manfred.bene...@inf.tu-dresden.de
Datum:
Wed, 27 Jan 2010 13:28:42 +0100
An:
sub...@bugs.debian.org
An:
sub...@bugs.debian.org
Subject: libc6: reproducable segfault in printf / vfprintf
Package: libc6
Version: 2.10.2-2
Justification: breaks the whole system
Severity: critical
after found a segfault problem in libc6 i have tried to construct a
minimal programm, that produce that error.
the following code produces this segfault. changing the last %5$s to
%1$s or removing one part, the segfaults disappear.
-
#include stdlib.h
#include stdio.h
int main(int argc, char **argv)
{
printf(%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%1$s%5$s
,,1, , , );
return 0;
}
-
compiled with gcc -g test.c (gcc-4.3.4-6)
Bug#514137: no a bug
getopt/getopt_long is actually not supposed to return ':' if the optstring does not _begin_ with a colon (e.g. :g:) or a +/- sign followed by a colon (e.g. +:g - this actually has another bug, but that's not what this report is about). -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#566297: getpwuid -- perl 5.10
On Mon, Jan 25, 2010 at 04:03:38PM -0700, Dave Serls wrote: On Mon, 25 Jan 2010 21:47:38 +0100 Aurelien Jarno aurel...@aurel32.net wrote: On Mon, Jan 25, 2010 at 01:14:28PM -0700, Dave Serls wrote: On Mon, 25 Jan 2010 21:06:49 +0100 Aurelien Jarno aurel...@aurel32.net wrote: On Mon, Jan 25, 2010 at 11:38:13AM -0700, Dave Serls wrote: On Mon, 25 Jan 2010 18:23:03 +0100 Aurelien Jarno aurel...@aurel32.net wrote: Dave Serls a écrit : Generates many messages of the form: ypserv[1349]: refused connect from 192.168.1.1:35691 to procedure ypproc_match (dashs.denver.co.us,passwd.adjunct.byname;-1) I guess it is on the server right? This mesages is there, as it refuses to serve a passwd.adjunct.byname to a non-priviledged user (coming from a port = 1024). Yes, the ypserv on the old Mandrake system gives the error. which appear to be provoked by some NSS call from 'wget'. This was never the case with previous libnss_nis.so I've narrowed down the source of the NIS ypmatch call to a invocation of the getpwuid() primitive in perl 5.10.0. That's strange, because with the patch to fix the NIS shadow leak, passwd.adjunct.byname calls have been removed for normal calls, and are now only done when querying shadow entries. Have you tried to reproduce the bug by running a simple C code calling getpwuid()? OK, I'll try that now. A straight call to getpwuid does not generate the error. So it must be something extra that perl 5.10 is doing in its call. Also, can you please share the contents of your /etc/nsswitch.conf? it is attached. I might add that there are no regular user entries in the local passwd/shadow files for the work station, so NIS must be used. I changed the code in the perl script GrabWeather to not use the getwpuid primitive and almost all the 'ypmatch ' errors have stopped. There is one that occurs out of the morning anacron of cron.daily that I can't locate yet. Thanks for the info, I have been able to reproduce the problem here. Can you please confirm that even before you get this same kind of lines with shadow.byname instead (at least with the default ypserv config)? I'm not clear on your intent. Are you saying that the yp server should previously (old libc6) have been emitting errors indicating shadow.byname instead of passwd.adjunct.byname? In my tests, it previously output: Jan 25 19:46:24 nis ypserv[2531]: refused connect from 10.243.120.26:57469 to procedure ypproc_match (aurel32,shadow.byname;-1) Now it outputs: Jan 25 19:55:12 nis ypserv[2531]: refused connect from 10.243.120.26:35205 to procedure ypproc_match (aurel32,shadow.byname;-1) Jan 25 19:55:12 nis ypserv[2531]: refused connect from 10.243.120.26:40967 to procedure ypproc_match (aurel32,passwd.adjunct.byname;-1) In other words two lines instead of one. Does it matches what you see? It may actually depends on what you have in /etc/ypserv.conf. Prior to the libc6 update, I received no messages of that type in the syslog of the yp server. After the update I began receiving pairs like: Jan 23 08:14:00 dashs ypserv[1349]: refused connect from 192.168.1.1:33472 to procedure ypproc_match(dashs.denver.co.us,passwd.adjunct.byname;-1) Jan 23 08:14:00 dashs ypserv[1349]: refused connect from 192.168.1.1:50897 to procedure ypproc_match (dashs.denver.co.us,passwd.adjunct.byname;-1) Can you please share your /etc/ypserv.conf on the server? With the default configuration, I also see those messages, but in addition to the shadow.byname messages. In the default configuration file, they have the same access right. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: severity of 538916 is normal
Processing commands for cont...@bugs.debian.org: severity 538916 normal Bug #538916 [libc6.1-dev] libc6.1-dev: Conflicting definitions in linux/ptrace.h and sys/ptrace.h on ia64 Severity set to 'normal' from 'important' thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Processed: Re: Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails
Processing commands for cont...@bugs.debian.org: forwarded 563882 http://sourceware.org/bugzilla/show_bug.cgi?id=11230 Bug #563882 [libc6.1] ia64: memchr overshots Set Bug forwarded-to-address to 'http://sourceware.org/bugzilla/show_bug.cgi?id=11230'. thanks Stopping processing here. Please contact me if you need assistance. Debian bug tracking system administrator (administrator, Debian Bugs database) -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563882: git-core FTBFS on ia64: t1001-read-tree-m-2way.sh test fails
forwarded 563882 http://sourceware.org/bugzilla/show_bug.cgi?id=11230 thanks Hi Aurelian, Aurelien Jarno wrote: On Tue, Jan 26, 2010 at 04:06:32PM -0600, Jonathan Nieder wrote: FYI: http://sourceware.org/bugzilla/show_bug.cgi?id=10162 Maybe glibc 2.11.1 (which includes a cherry-pick of commit 6622141) will fix this. This patch is already included in the Debian libc6 package. Drat. It actually may be the cause of the problem you reported. FWIW the problem was present using libc 2.10.1-1 in October of last year, before that patch was written. A test a few weeks earlier using 2.9-26 was fine, so it does look like the fix to BZ#10162 introduced this bug, yes. Hope that helps, Jonathan [1] You can see the regression window in the build logs here: https://buildd.debian.org/build.php?pkg=git-corearch=ia64 First failure is https://buildd.debian.org/fetch.cgi?pkg=git-corever=1:1.6.5.2-1arch=ia64stamp=1256693639file=log -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#563882: (no subject)
On Wed, Jan 27, 2010 at 12:33:26PM +0100, Aurelien Jarno wrote: On Wed, Jan 27, 2010 at 11:47:42AM +0100, Petr Baudis wrote: This patch is already included in the Debian libc6 package. It actually may be the cause of the problem you reported. This problem is already fixed in 2.11.1 or master. Have you also applied the proper _second_ patch in that bug? C.f. my and H.J.Lu's comments and mailing list posts. Here is the patch that is applied. It makes memchr.S identical to the current HEAD version. I guess the problem is *not* fixed in HEAD or 2.11.1. What is fixed is the stratcliff testsuite problem, and this fixes may have actually introduced this problem. This bug is not introduced by this patch. However in what not present in 2.7, and has been introduced somewhere between 2.7 and 2.10, I haven't investigated yet. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurel...@aurel32.net http://www.aurel32.net -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
