Re: Bug#666391: valgrind: 64-bit valgrind can not run 32-bit binary due to missing/incorrect debug symbols
On Mon, Apr 02, 2012 at 05:37:54PM +0200, Sebastian Rasmussen wrote: I have problems running 32-bit binaries in my 64-bit valgrind, however this likely a bug related to eglibc or possibly in how valgrind depends on eglibc's packages. I expect that both 32-bit and 64-bit binaries can be run inside valgrind (or at least that there are packages recommended by valgrind that I install to do so). The problem is there is not debug symbols packaged as a biarch package in Debian, meaning that valgrind is mostly useless used with libc6-i386. In other words there is no libc6-i386-dbg package as you note later: For 64-bit binaries (shown above) /lib/x86_64-linux-gnu/ld-2.13.so (installed by libc6) does have a .gnu_debuglink section pointing to the debug-version of located in /usr/lib/debug (more specifically /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.13.so) which is installed by libc6-dbg. To behave properly, you have two roads, either ask the libc maintainer to provide a libc6-i386-dbg package, which between us, wouldn't really be the proper way, or more simply, use multiarch. For that: # dpkg --add-architecture i386 # apt-get update # apt-get install libc6-i686:i386 libc6-dbg:i386 For *some* reason I don't really understand, the first time I ran your testing-32 I had to specify the full path to the ld.so in this fashion: $ valgrind /lib/i386-linux-gnu/ld-2.13.so ./testing-32 But it's now fine and runs properly when I just do: $ valgrind ./testing-32 I've no real clue on *why* it didn't work the first time, probably some kind of ld.so.cache or something. I've put the glibc maintainer in the loop because it's not clear to me why valgrind ./testing-32 failed in the first instance, maybe he'll have a clue, I suspect that ldconfig didn't do the right thing because of the fact that I have three libc's: libc6:amd64, libc6-i686:i386 and libc6-i386:amd64… and it probably picked the wrong ones. Cheers, -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403084714.ga5...@madism.org
Re: Bug#666391: valgrind: 64-bit valgrind can not run 32-bit binary due to missing/incorrect debug symbols
On Tue, Apr 03, 2012 at 10:47:14AM +0200, Pierre Habouzit wrote: On Mon, Apr 02, 2012 at 05:37:54PM +0200, Sebastian Rasmussen wrote: I have problems running 32-bit binaries in my 64-bit valgrind, however this likely a bug related to eglibc or possibly in how valgrind depends on eglibc's packages. I expect that both 32-bit and 64-bit binaries can be run inside valgrind (or at least that there are packages recommended by valgrind that I install to do so). The problem is there is not debug symbols packaged as a biarch package in Debian, meaning that valgrind is mostly useless used with libc6-i386. In other words there is no libc6-i386-dbg package as you note later: For 64-bit binaries (shown above) /lib/x86_64-linux-gnu/ld-2.13.so (installed by libc6) does have a .gnu_debuglink section pointing to the debug-version of located in /usr/lib/debug (more specifically /usr/lib/debug/lib/x86_64-linux-gnu/ld-2.13.so) which is installed by libc6-dbg. To behave properly, you have two roads, either ask the libc maintainer to provide a libc6-i386-dbg package, which between us, wouldn't really be the proper way, or more simply, use multiarch. For that: # dpkg --add-architecture i386 # apt-get update # apt-get install libc6-i686:i386 libc6-dbg:i386 For *some* reason I don't really understand, the first time I ran your testing-32 I had to specify the full path to the ld.so in this fashion: $ valgrind /lib/i386-linux-gnu/ld-2.13.so ./testing-32 But it's now fine and runs properly when I just do: $ valgrind ./testing-32 I've no real clue on *why* it didn't work the first time, probably some kind of ld.so.cache or something. I've put the glibc maintainer in the loop because it's not clear to me why valgrind ./testing-32 failed in the first instance, maybe he'll have a clue, I suspect that ldconfig didn't do the right thing because of the fact that I have three libc's: libc6:amd64, libc6-i686:i386 and libc6-i386:amd64… and it probably picked the wrong ones. If that helps: ld.so.conf:include /etc/ld.so.conf.d/*.conf ld.so.conf.d/i486-linux-gnu.conf:# Multiarch support ld.so.conf.d/i486-linux-gnu.conf:/lib/i386-linux-gnu ld.so.conf.d/i486-linux-gnu.conf:/usr/lib/i386-linux-gnu ld.so.conf.d/i486-linux-gnu.conf:/lib/i486-linux-gnu ld.so.conf.d/i486-linux-gnu.conf:/usr/lib/i486-linux-gnu ld.so.conf.d/libc.conf:# libc default configuration ld.so.conf.d/libc.conf:/usr/local/lib ld.so.conf.d/x86_64-linux-gnu.conf:# Multiarch support ld.so.conf.d/x86_64-linux-gnu.conf:/lib/x86_64-linux-gnu ld.so.conf.d/x86_64-linux-gnu.conf:/usr/lib/x86_64-linux-gnu ld.so.conf.d/zz_i386-biarch-compat.conf:# Legacy biarch compatibility support ld.so.conf.d/zz_i386-biarch-compat.conf:/lib32 ld.so.conf.d/zz_i386-biarch-compat.conf:/usr/lib32 Though I'm totally unable to reproduce it so maybe we can waive it as a spurious bug. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120403085454.gb5...@madism.org
Bug#608061: libc6: dns-lookup unusable in mixed ipv4/ipv6-networks
tag 608061 + unreproducible thanks Your trace proves nothing, this is a tcpdump with no data inside, you give actually no way to reproduce the problem. On Sun, 26 Dec 2010 20:22:28 +0100 Felix Schueller fs-linux_...@fschueller.eu wrote: Package: libc6 Version: 2.11.2-7 Severity: important Tags: ipv6 When looking up an ip-address on an ipv6-enabled system, libc tries to find an A and an -record. But, if some machine has only an A but no record it returns host-not-found (see tcpdump below) So one can only connect (with e.g. iceweasel, w3m, telnet) to hosts with both A and records (or server with cname-records) On an ipv4-only machine this can be solved by disabling ipv6 completly, but on a dualstack-machine, i found no way to fix this. I found this on bug on two ways, an installing squeeze via d-i (the ipv4 only machine) and via upgrading from lenny to squeeze I do have an ipv6 enabled machine here, and I can connect to ipv4-only hosts just fine with w3m or any other programs. Have you modified your /etc/gai.conf, are you using nscd with hosts caching ? -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20101227114341.6a9b3...@madism.org
Bug#588180: dist-upgrade from lenny to squeeze with tons of warning messages
On Tue, Jul 06, 2010 at 11:32:58AM +0200, Aurelien Jarno wrote: Andre Zepezauer a écrit : Package: locales today I installed lenny (5.0.2 base-system only) and afterwards performed an apt-get dist-upgrade to squeeze. While upgrading, endless warning messages were printed to the screen: perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LANG = en_US.UTF-8 are supported and installed on your system. perl: warning: Falling back to the standard locale (C). locale: Cannot set LC_CTYPE to default locale: No such file or directory locale: Cannot set LC_MESSAGES to default locale: No such file or directory locale: Cannot set LC_ALL to default locale: No such file or directory I had cancel the upgrade to examine these warning messages. All were the same (see above). At this time the environment variables LANGUAGE and LC_ALL were in fact unset. And LANG had a value of en_US.UTF-8 (see above). After remove/install locales, editing /etc/defaults/locals, running dpkg-reconfigure locales, logout/login, my environment looked like this: LANGUAGE=en_US.UTF-8 LC_ALL (unset) LANG (unset) I continued the dist-upgrade, but now without any warnings. Thus it seems to me, that in lenny it is assumed that at least LANG is set, but squeeze assumes LANGUAGE to be set. If this is true, it would be nice to see the upgrade process handling it somewhat better. The problem is that the locales packages is reconfigured very late in the upgrade process. There is nothing we can do, the messages will stop at the end of the upgrade. Actually there is, making perl STFU. -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100706163216.gj23...@madism.org
Re: problem with backtrace() after system update
On Wed, Jan 13, 2010 at 01:01:27PM +0100, Bartek 'BaSz' Szurgot wrote:
Aurelien Jarno wrote:
Bartek 'BaSz' Szurgot a écrit :
hi,
Hi,
some time ago i wrote C++ code to save backtrace in a vector of
strings. it worked fine until one of system updates (~month
ago), when it suddenly started to show too short listening(s).
i've tried example from manual (man backtrace) to verify this,
and it does not work properly too. example output is:
$ gcc -Wall -g3 -rdynamic main.c ./a.out 10
backtrace() returned 4 addresses
./a.out(_Z7myfunc3v+0x1c) [0x400b28]
./a.out [0x400ba9]
./a.out(_Z6myfunci+0x23) [0x400bce]
./a.out(_Z6myfunci+0x1c) [0x400bc7]
where there should be 10 calls on stack. raising number given
as an argument does not change output.
What are the missing entries you expect?
in the man's example function myFunc() is recurrent. here it should be
call 10 times. this is its body taken from man:
void myfunc(int ncalls)
{
if (ncalls 1)
myfunc(ncalls - 1);
else
myfunc2();
}
example output provided in man does show more calls to myFunc() (i.e. 3):
$ cc -rdynamic prog.c -o prog
$ ./prog 3
backtrace() returned 8 addresses
./prog(myfunc3+0x5c) [0x80487f0]
./prog [0x8048871]
./prog(myfunc+0x21) [0x8048894]
./prog(myfunc+0x1a) [0x804888d]
./prog(myfunc+0x1a) [0x804888d]
./prog(main+0x65) [0x80488fb]
/lib/libc.so.6(__libc_start_main+0xdc) [0xb7e38f9c]
./prog [0x8048711]
gcc does tail-recursion optimization, hence in the previous code it's
normal to have a short backtrace.
--
·O· Pierre Habouzit
··Omadco...@debian.org
OOOhttp://www.madism.org
--
To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531698: [locales] dpkg-reconfigure locales should allow to select none/all
reassing 531698 debconf thanks On Wed, Jun 03, 2009 at 01:05:02PM +0200, Simon Eugster wrote: Package: locales Version: 2.9-13 Severity: wishlist --- Please enter the report below this line. --- If by default about 20 or more locales are selected in the list, deactivating all but the really required ones is tedious. A select/unselect all option would be really nice. This actually is a debconf interface, reassigning to it -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#531397: tzdata: Error message at boot and halt : Cannot access the Hardware Clock via any known method
reassign 531397 util-linux thanks On Mon, Jun 01, 2009 at 12:05:30PM +, giggzounet wrote: oopps sorry. the bug comes from hwclock and so from util-linux. You can close ths bug...I will report to util-linux. Have a nice day Guillaume -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org -- ·O· Pierre Habouzit ··Omadco...@debian.org OOOhttp://www.madism.org -- To UNSUBSCRIBE, email to debian-glibc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
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#504196: glibc: experimental upgrade breaks epiphany-browser
On Sat, Nov 01, 2008 at 03:45:56PM +, Johannes Berg wrote: Package: glibc Version: 2.8+20080809-1 Severity: normal I have no idea why, but upgrading to libc6 from experimental on an otherwise mostly unstable system breaks epiphany-browser, it will segfault right away at start. Could you at least care to give a backtrace with libc6-dbg installed please ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpeqabliWGKj.pgp Description: PGP signature
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#492892: glibc: glibc-2.7/patches/hurd-i386 patches fails
On Wed, Jul 30, 2008 at 02:17:35PM +, Herbert P Fortes Neto wrote: Ok Pierre. But it is not glibc*/debian/patches/series it is glibc-2.7/build-tree/glibc-2.7/patches/series You are kidding me right ? You know how quilt works right ? ┌─(16:51) └[artemis] cd glibc*/ ┌─(16:54) └[artemis] pwd /home/madcoder/debian/tmp/glibc-2.7 ┌─(16:51) └[artemis] ./debian/rules patch mkdir -p build-tree cd build-tree tar -xjf /home/madcoder/debian/tmp/glibc-2.7/glibc-2.7ds1.tar.bz2 [...] Applying patches...successful. ./debian/rules patch 8,00s user 4,31s system 30% cpu 40,712 total ┌─(16:52) └[artemis] readlink build-tree/glibc-*/debian/patches /home/madcoder/debian/tmp/glibc-2.7/debian/patches I mean come on, every single buildd has built the glibc fine. _you_ are somehow shooting yourself in the foot, you probably messed up with some symlinks I don't know, but please, sort this out on your own. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpLWvN4Jb6VS.pgp Description: PGP signature
Bug#492892: glibc: glibc-2.7/patches/hurd-i386 patches fails
On Wed, Jul 30, 2008 at 04:33:55PM +, Herbert P Fortes Neto wrote:
You are kidding me right ?
No
I mean come on, every single buildd has built the glibc fine. _you_
are somehow shooting yourself in the foot, you probably messed up
with some symlinks I don't know, but please, sort this out on your
own.
I have already did it two days ago.
And I am not have been rude.
I'm not rude, I'm annoyed you don't connect the dots by yourself, but
here is it spelled out:
build-tree/glibc-2.7/patches is a symlink to debian/patches IOW
build-tree/glibc-2.7/patches/series and debian/patches/series ARE
SUPPOSED TO BE THE SAME.
It's note the case for you, so probably, in your environment the symlink
points to another place, that happes to also be a glibc quilt patch
queue, just not the proper one. I have _no clue_ on the how and the why,
and like tbm said, it's probably because of your build envirnoment,
probably because the glibc (or quilt I don't know) does the symlink in
an absolute way instead of relative, which is not
{chroot,NFS,mv,renames,...}-proof, and probably emdebian or you is doing
one of those things.
And given the really tiny amount of information that I had to forcefully
get from you, it's hard to say what. Note that the fact that you were
building the glibc using emdebian should have been the first thing you
should have said, and you should have tried by yourself that the glibc
builds fine without emdebian, hence have understood by yourself that
emdebian was at fault, and bug the emdebian people instead.
So no, I'm not rude, I'm annoyed I have to be your brain remotely for a
problem that is after all not glibc related.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpZNjzWTNJTO.pgp
Description: PGP signature
Bug#492892: glibc: glibc-2.7/patches/hurd-i386 patches fails
On Tue, Jul 29, 2008 at 05:05:14PM +, Herbert P Fortes Neto wrote: Package: glibc Severity: serious Justification: no longer builds from source Today the compile failed to apply the patches. The problem was solved when I removed /build-tree/glibc-2.7/patches/hurd-i386/*patch entries from build-tree/glibc-2.7/patches/series The problem is at the patch-files from the original source. Huh, what are you talking about ? [0] seems to prove that the glibc builds rather fine. On which arch have you this issue ? [0] http://buildd.debian.org/~jeroen/status/package.php?p=glibcsuite=unstable -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRmVWwgGEih.pgp Description: PGP signature
Bug#492892: glibc: glibc-2.7/patches/hurd-i386 patches fails
tag 492892 + unreproducible moreinfo thanks On Tue, Jul 29, 2008 at 07:31:02PM +, Herbert P Fortes Neto wrote: On Tue, 29 Jul 2008 19:33:04 +0200 Pierre Habouzit [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 05:05:14PM +, Herbert P Fortes Neto wrote: Package: glibc Severity: serious Justification: no longer builds from source Today the compile failed to apply the patches. The problem was solved when I removed /build-tree/glibc-2.7/patches/hurd-i386/*patch entries from build-tree/glibc-2.7/patches/series The problem is at the patch-files from the original source. Huh, what are you talking about ? [0] seems to prove that the glibc builds rather fine. On which arch have you this issue ? [0] http://buildd.debian.org/~jeroen/status/package.php?p=glibcsuite=unstable i386. Building packages to emdebian i386 Step by step debootstrap sid /path/to/dir copy networking files mount proc /path/to/dir/proc -t proc LANG=C chroot /path/to/dir emsource -v glibc debuild Applying patches.. failed check patch-log Some files, one or two were mising in hurd-i386, so I removed these hurd-i386 from series file and I can't explain that, patches apply here, so please at least give sensible informations like e.g. patch log ? I mean your bug report is useless at best for now, I have no information on what breaks, why, which arch, you should really know better. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpaW1ZQuvW3U.pgp Description: PGP signature
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#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
severity 491809 important retitle 491809 DNS stub resolver could be hardened. thanks On Fri, Jul 25, 2008 at 10:06:01PM +, Florian Weimer wrote: reopen 491809 thanks * Pierre Habouzit: Kaminsky agrees confirm the issue, so I can say for sure that the glibc isn't vulnerable to the attack he describes, as it needs a resolver that caches additionnal RRs, which the glibc doesn't do. As of attacks that would use non randomized source port use, this is addressed by recent kernels hence is fixed enough. I've trouble parsing what you wrote. What I mean, is that the glibc performs no additionnal RR caching, which is how the attack poisons caches. Moreover the glibc is _not_ a recursive resolver either. And finally it also uses random source ports, which is the simplest way to prevent Kaminsky's attack. Based on information provided at the DNS summit, I do think we should harden the glibc stub resolver. That's another matter which doesn't warrant a critical severity at all. The glibc stub resolver is already safe enough by many standards. I don't deny it could be hardened though (Improving the RNG is probably not a bad idea). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp0uU6riVYD6.pgp Description: PGP signature
Bug#491809: libc6: DNS spoofing vulnerability [CVE-2008-1447]
On Tue, Jul 22, 2008 at 03:24:06PM +, Florian Weimer wrote: * Aurelien Jarno: Currently, there is no suitable patch to backport. I hope that improved port randomization will be available shortly. You mean a patch for the kernel? Yes, one for the kernel, and one for the transaction ID generation in the libc resolver, too. (Oh, and shortly == next week or so.) Assuming the TID generator for the glibc is good enough and that the flaw is the one described in [0], then the glibc code (even nscd) isn't vulnerable, because it doesn't cache or even look at the additional records. The problems with QID randomization are quite orthogonal, and it's a problem known for 20 years now (using last QID+1 isn't really an option ;p). Having a better random number generator will probably help, but quite doesn't require such a severity (as there is already randomization of the QIDs, maybe not a perfect one). So unless you have further non yet disclosed informations, I'd suggest reconsidering the DSA. [0] http://blogs.buanzo.com.ar/2008/07/matasano-kaminsky-dns-forgery.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpdjnl4NkwlT.pgp Description: PGP signature
Bug#456531: setting package to libc6.1-pic glibc libc0.3-dev libc0.1-i686 libc0.3-prof libc6.1-dev libc6-udeb libc6-sparcv9b libc6.1-dbg libc0.1-pic libc6-dev-mips64 libc6.1-prof libc6-powerpc nscd li
# Automatically generated email from bts, devscripts version 2.10.20 # # glibc (2.7-12) UNRELEASED; urgency=low # # * Add any/cvs-strerror_r.diff to make strerror_r() actually thread-safe #Closes: #456531. # package libc6.1-pic glibc libc0.3-dev libc0.1-i686 libc0.3-prof libc6.1-dev libc6-udeb libc6-sparcv9b libc6.1-dbg libc0.1-pic libc6-dev-mips64 libc6.1-prof libc6-powerpc nscd libc0.3-udeb libc6.1-udeb libc0.1-udeb libc6-ppc64 locales libc6-sparc64 libc6-prof libc0.1-dev libc6-dev libc6-i386 glibc-doc libc6-dev-sparc64 glibc-source libnss-files-udeb libc6-dev-amd64 libc6-i686 libc0.1-i386 libc6-mips64 libnss-dns-udeb libc6-dev-powerpc libc0.1-prof locales-all libc0.1 libc6.1-alphaev67 libc6 libc6-xen libc0.1-dev-i386 libc6-dev-s390x libc0.1-dbg libc6.1 libc6-s390x libc6-pic libc6-dev-i386 libc0.3 libc6-amd64 libc0.3-dbg libc6-mipsn32 libc6-dev-mipsn32 libc6-dev-ppc64 libc6-dbg libc0.3-pic tags 456531 + pending -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: pgettext() availability in Debian?
On Fri, Mar 14, 2008 at 03:44:43PM +, Adam Spragg wrote: Dear Debian glibc maintainers, I am currently trying to i14e[0] a bit of software that I'm writing on Debian GNU/Linux, and have been reading up on gettext and its associated applications and libraries. I have figured out that I need use contexts to distinguish between some short strings in my application. To this end, I've created a sample .pot file and translated .po files with the requisite msgid, msgstr and msgctxt lines. However, in order to use the strings at runtime, I need to be able to call [d[c]]pgettext(), as described in the gettext manual[1]. those come in gettext.h (that is explained in the manual that you quote), which is in /usr/share/gettext/gettext.h. Though you should _not_ use that file directly, but run gettexttize on your project to install all the gettext stuff, including gettext.h. This isn't a glibc issue at all. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQMmrvwKAcH.pgp Description: PGP signature
Bug#467609: failed assertion in nscd (hstcache.c:364) on host name lookup
On Tue, Feb 26, 2008 at 01:46:03PM +, Fabien COUTANT wrote: Package: nscd Version: 2.3.6.ds1-13etch5 Severity: grave Justification: renders package unusable This looks a lot like #451552, except the bug *still* occurs on more recent versions. I expect this grave bug would have been fixed _in_etch_ by the time... Setting debug-level to 16383 in /etc/nscd.conf, and running nscd -d in a terminal gives the following crash before a few minutes to hours (even when nscd was started after invalidating the caches with nscd -i): [...cut...] 10152: add new entry adtech.panthercustomer.com of type GETHOSTBYNAME for hosts to cache (first) 10152: Reloading adtech.panthercustomer.com in hosts cache! 10152: add new entry adtech.panthercustomer.com of type GETHOSTBYNAME for hosts to cache (first) 10152: Reloading adtech.panthercustomer.com in hosts cache! 10152: add new entry adtech.panthercustomer.com of type GETHOSTBYNAME for hosts to cache (first) 10152: Reloading adtech.panthercustomer.com in hosts cache! 10152: add new entry adtech.panthercustomer.com of type GETHOSTBYNAME for hosts to cache (first) 10152: Reloading ecx.images-amazon.com in hosts cache! nscd: hstcache.c:364: cache_addhst: Assertion `hst-h_addr_list[1] == ((void *)0)' failed. Aborted Of course, after the crash all networking is slowed to a pain since name lookups aren't cached any more... and the lack of cache also has impacts on other tables :( Since the process isn't rock solid, it has become unusable... one can't go restart it every time it crashes, it would be far too often. Please don't use the hosts cache, it's documented in lenny, not in etch sadly, but it has way too many issues. If you need a lightweight *working* DNS cache, use pdnsd. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpANIV99xK8O.pgp Description: PGP signature
Bug#466702: locales: Cannot correctly set locale after update to 2.7-8
On Wed, Feb 20, 2008 at 02:13:42PM +, Krishnamurti L. L. V. Nunes wrote: Package: locales Version: 2.7-8 Severity: important After upgrade to version 2.7-8 most of my software does not show the selected language because locales does not keep the selected language, as shown bellow: $ locale -a C POSIX en_US en_US.iso88591 en_US.utf8 pt_BR pt_BR.iso88591 pt_BR.utf8 Content of /etc/environment : LANGUAGE=pt_BR.UTF-8:pt_BR:pt:pt_PT LANG=pt_BR.UTF-8 are you sure /etc/environment is sourced by your shell ? dpkg-reconfigure won't source it again for you. The fact that for you LANG is empty means that /etc/environment is not sourced, which is a problem of your shell, not the libc. If you're under X, you need to logout, if under a linux console either to run source /etc/environment or logout/login again. FWIW it works here properly, and I see no reason why it shouldn't. Please reopen the bug if needed. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp6AxkordPLr.pgp Description: PGP signature
Bug#466519: ltrace of an svn update
On Tue, Feb 19, 2008 at 10:03:48AM +, Ivan Sergio Borgonovo wrote: I noticed in the other bug report it was asked to include an ltrace... This is the ltrace of an svn update. You had libc6-dbg installed when you ran it ? because I see no libc calls which is odd. A strace may help too please. TIA -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpAQyYUzbRfW.pgp Description: PGP signature
Bug#466491: libc6: gettimeofday() in /libe/libc.so.6 causes SIGSEGV
tag 466491 + moreinfo thanks On Tue, Feb 19, 2008 at 04:56:58AM +, Robert Clayton Barnes wrote: Package: libc6 Version: 2.7-6 Severity: important Applications (such as mplayer and vlc) that call gettimeofday() from /lib/libc.so.6 get a SIGSEGV. See gdb output below: the gdb output isnt enough. gettimeofday takes pointers, if the pointers are FUBAR, it's normal it segfaults. Please provide a full backtrace. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYvnPTw6NjF.pgp Description: PGP signature
Re: Proposal(s) for handling libqt3-mt situation
On Mon, Feb 18, 2008 at 08:39:51AM +, Steve Langasek wrote: On Sat, Feb 16, 2008 at 10:17:33AM +0100, Pierre Habouzit wrote: digikam k3b kcontrol kdirstat kexi konq-plugins konqueror ktorrent libk3b3 libmyth-0.20.2 mythdvd mythmusic mythtv-backend pdfedit trustedqsl virtualbox-ose Okay that's quite a few, so the Conflict option sucks. Well, considering this is a very small percentage of the total libqt3 reverse-deps, I think it's at least a less bad solution than a library transition. I don't know for sure, but would expect the impact on dist-upgrades to be manageable. Well, actually, it seems that (with our more extended search) stat64 and friends are the 3 sole missing symbols, and they will be hacked back in, as qt3 is in the leave on the long term (probably will still be here in lenny+1, probably not in lenny+2). We understand fully why they are missing now, and that's why we're sure that (1) the problem is limited to Qt and (2) it won't show up again[0]. There is an experimental package with the symbols hacked back in and built with -O2, we should avoid (1) a transition (2) conflicts (3) delaying kde 3.8.9 upload. I'll still check that none of the other symbols that got missing due to the use of -O2 were really used in any qt3 rdeps somewhere in the week though. Thanks a _lot_ to Modestas for his invaluable help on that issue. [0] basically you need to (1) be a library (2) in c++ (3) built with -O0 (4) with an old glibc (= 2.6) to get the symbols. We hope qt3 was the sole library meeting these conditions, and if not, the hack will be the same: reinstate the missing symbols back in, as the real source of the bug isn't really libc6-dev, but the fact that the library was built with -O0 despite the policy. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgprOCk5sm3z4.pgp Description: PGP signature
Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 08:08:17AM +, Matthew Rosewarne wrote: On Thursday 14 February 2008, Modestas Vainius wrote: Hi, As of writing, libqt3-mt ABI breakage caused serious 16 bugs (#464946 friends) to be reported by our users. So I think it's high time we took some action today or tommorow to unbreak software affected. I'm concerned about Debian unstable users even though in theory they shouldn't be using unstable if they don't known how to downgrade packages. So this mail is all about how to deal with this situation having two main criteria in mind: I've looked through all C++ packages (libsdtc++6 rdepends), and I think I have a complete list of broken pacakges. They are: digikam k3b kcontrol kdirstat kexi konq-plugins konqueror ktorrent libk3b3 libmyth-0.20.2 mythdvd mythmusic mythtv-backend pdfedit trustedqsl virtualbox-ose Okay that's quite a few, so the Conflict option sucks. Here is another plan, tell me what you think, we put a debian specific hack in the glibc to reenable the extern inlines for _ONLY_ the packages that ask for it, for lenny, and remove it in lenny+1. Qt _has_ to use it to build, though digikam and friends won't, so that they will _stop_ using the damn symbols. This way partial upgrades to lenny works, and in lenny+1 the symbols just disappear for good. No Conflicts are needed, We only need a list of _library_ packages that have the stat (and other symbols) defined reuploaded with a -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS. Then a binNMU campaign of the broken _packages_ has to follow (digikam, k3b, ... ) so that they loose their wrong *UND* symbols for good. I think it's a fair middle ground solution. Thoughts ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQaduxHExK9.pgp Description: PGP signature
Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 10:52:01AM +, Modestas Vainius wrote: Hi, 2008 m. February 16 d., Saturday, Pierre Habouzit rašė: Okay that's quite a few, so the Conflict option sucks. Here is another plan, tell me what you think, we put a debian specific hack in the glibc to reenable the extern inlines for _ONLY_ the packages that ask for it, for lenny, and remove it in lenny+1. Ok, so it's actually a debate whether to readd missing symbols to affected libraries themselves or to libc6-dev. If Matthew is correct, all packages except trustedqsl are victims of libqt3-mt. By the way, I'm not sure if tsql is a problem (atoi is versioned?): $ objdump -tT /usr/bin/tqsl | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -tT /usr/bin/tqslcert | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi $ objdump -Tt /usr/lib/libtqsllib.so.1.0.0 | grep atoi DF *UND* 0015 GLIBC_2.2.5 atoi atoi is a libc symbol, so I don't see a problem with that: $ objdump -T /lib/libc-2.7.so|grep atoi 00032530 gDF .text 0015 GLIBC_2.2.5 atoi The fact that atoi is clearly versionned should have given you a hint ;P If what you say was true, ktorrent 2.2.5.dfsg.1-1 should not depend on fstat64, because 1. ktorrent 2.2.5.dfsg.1-1 was uploaded on Wed, 06 Feb 2008 23:07:08 +0200, hence built against libc6-dev (= 2.7) without extern inlines in sys/stat.h That's essentially the same as it would be building without -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 2. qt-x11-free 3.3.7-9 was uploaded on Wed, 26 Sep 2007 21:42:24 +0200, hence built against libc6-dev ( 2.7) with extern inlines in sys/stat.h present. That's essentially the same as it would be building with -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK 3. ktorrent 2.2.5.dfsg.1-1 was linked against qt-x11-free 3.3.7-9 (app, not using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK, was linked against lib, using -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK). As you see, all conditions were met, but, unfortunately, ktorrent 2.2.5.dfsg.1-1 still depends on exported fstat64 I absolutely don't understand how that can be true. I mean it doesn't make sense, ktorrent gets the symbol from the libc6, and it just emits an undefined symbol because qt3 provides it at the time, there is no way it gets it another way. So I'll try to redo a proper test where I'm actually really sure of what I have during the build instead of probable speculations. No Conflicts are needed, We only need a list of _library_ packages that have the stat (and other symbols) defined reuploaded with a -D_USE_DEBIAN_GLIBC_EXTERN_INLINE_HACK in the CFLAGS. Do you want to add hack to lib6-dev just for Qt3? I fear it's not _only_ qt3. And yes, given that there are 20+ packages affected in the end, I'm more than ready to do it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp1ihFnVFxqS.pgp Description: PGP signature
Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 10:58:13AM +, Pierre Habouzit wrote: I absolutely don't understand how that can be true. I mean it doesn't make sense, ktorrent gets the symbol from the libc6, and it just emits an undefined symbol because qt3 provides it at the time, there is no way it gets it another way. So I'll try to redo a proper test where I'm actually really sure of what I have during the build instead of probable speculations. Okay, so for the others, here is what happens for real: * the extern inlines from sys/stat.h are just gone, and that's just normal in fact. * /usr/lib/libc.so is a linker script that pulls /lib/libc-2.7.so _and_ /usr/lib/libc_nonshared.a. * the latter defines stat64 and friends as weak-symbols and alises to __xstat64 and friends. That's how when you link something that uses fstat64 it finds the symbol at link time, letting you the possibility to override it with your own implementation. The fact that the extern inlines were used at some point in the past _was_ a bug, and let qt3 divert those, which should have not happened in the first place. Sadly, when you link against qt3, it picks those symbols because it will always prefer symbols from a shared lib than from the .a IIRC, or it's due to the link order, anyways, it's not relevant. So with this new information, I'd say that the safest way is to re-add manually (I heard Modestas has a patch for that) the symbols to qt3. It's not pretty, but qt3 will disappear eventually, and it's not a problem to hack it that way, whereas reenabling the patch in the libc will concern more and more symbols with time, and has good chances to become an issue. I'm still not in favor of it. We should still look in the archive if other libraries have the symbols and deal on a per case basis. It seems c++ libraries are the one affected, C ones usually arent as extern inline has a different meaning in C (especially in GNU C 89). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgps4B2iXl9Mo.pgp Description: PGP signature
Re: Proposal(s) for handling libqt3-mt situation
On Sat, Feb 16, 2008 at 01:22:31PM +, Pierre Habouzit wrote: We should still look in the archive if other libraries have the symbols and deal on a per case basis. It seems c++ libraries are the one affected, C ones usually arent as extern inline has a different meaning in C (especially in GNU C 89). okay and to finish to nail the problem down: 18:16 MoDaX | libqt-mt is not built with -O2!! 18:16 mukidohime | Sweet zombie jesus! 18:16 mukidohime | Whose idea was that? 18:16 MoDaX | that's why it exposes stat64 and friends 18:17 MoDaX | libs built with -O2 does not 18:17 MoDaX | do not* 18:17 mukidohime | So *that's* why only Qt was affected... Which means that now I'm not only in favour to manually add the symbols to Qt3, but in fact it's also The Right Thing to do, Qt people, please sort out _your_ mess :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpmsooRbBtCq.pgp Description: PGP signature
Bug#465844: libc6: Can't upgrade from Etch
forcemerge 465753 465844 thanks On Fri, Feb 15, 2008 at 11:35:21AM +, Russell Coker wrote: Package: libc6 Version: 2.7-8 Severity: important see 465753 for a workaround this is likely to be a dpkg bug. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGxdPRNVCDb.pgp Description: PGP signature
Re: extern inline and ?stat64 fun in glibc
On Wed, Feb 13, 2008 at 11:21:46PM +, Sune Vuorela wrote: Hi! As many people know, som header change in libc6-dev made libqt3-mt (and maybe other packages) drop some symbols on one or more archs. For full details, see the thread starting here: http://lists.debian.org/debian-devel/2008/02/msg00439.html, especially the post by Pierre here: http://lists.debian.org/debian-devel/2008/02/msg00580.html For the result of this change, see the RC buglist against libqt3-mt The question is now - what to do? 1) Roll back the changes to libc6-dev and rebuild qt3 2) patch in those symbols in qt3 3) rename libqt3-mt and rebuild all 500 rdeps, including all of kde3. 4) something else ? I am currently most in favour of 1. And very much against 2. But hoping for 4. Well, I'd like to avoid (1) if possible. But please discuss and comment - and please keep me cc'ed. I am not subscribed to glibc list. Well, there is a possibility, the affected packages are ones that have undefined symbols on stat64 and that used to get their crack from another library (libqt3 here). We have to scan the whole archive for undefined symbols on stat64 and other alike symbols (we can probably find an exhaustive enough list, grep for __extern_inline in the libc6-dev basically). If that amount of packages is small, then the libraries that used to provide the symbols for them should have versionned conflicts, bump their shlibs, and then those packages should be binNMUed. Though this approach only works if there is (and I believe it's the case) few packages matching. What do you think ? [ basically for qt3 it seems it would be only 3 conflicts, we can live with that ] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQ9lwOx3VRH.pgp Description: PGP signature
Re: extern inline and ?stat64 fun in glibc
On Thu, Feb 14, 2008 at 10:47:00AM +, Pierre Habouzit wrote: On Wed, Feb 13, 2008 at 11:21:46PM +, Sune Vuorela wrote: Hi! As many people know, som header change in libc6-dev made libqt3-mt (and maybe other packages) drop some symbols on one or more archs. For full details, see the thread starting here: http://lists.debian.org/debian-devel/2008/02/msg00439.html, especially the post by Pierre here: http://lists.debian.org/debian-devel/2008/02/msg00580.html For the result of this change, see the RC buglist against libqt3-mt The question is now - what to do? 1) Roll back the changes to libc6-dev and rebuild qt3 2) patch in those symbols in qt3 3) rename libqt3-mt and rebuild all 500 rdeps, including all of kde3. 4) something else ? I am currently most in favour of 1. And very much against 2. But hoping for 4. Well, I'd like to avoid (1) if possible. But please discuss and comment - and please keep me cc'ed. I am not subscribed to glibc list. Well, there is a possibility, the affected packages are ones that have undefined symbols on stat64 and that used to get their crack from another library (libqt3 here). We have to scan the whole archive for undefined symbols on stat64 and other alike symbols (we can probably find an exhaustive enough list, grep for __extern_inline in the libc6-dev basically). If that amount of packages is small, then the libraries that used to provide the symbols for them should have versionned conflicts, bump their shlibs, and then those packages should be binNMUed. Though this approach only works if there is (and I believe it's the case) few packages matching. What do you think ? [ basically for qt3 it seems it would be only 3 conflicts, we can live with that ] FWIW the list of symbols on amd64 seems to be the one attached. Don't be afraid, there is a lot of guards to get them, and it's really likely we won't have any matches in the archive on UNDEFINED symbols on them. I don't have time to perform the scan yet though. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org __argp_usage __argz_next __cmsg_nxthdr __option_is_end __option_is_short __pthread_cleanup_routine __signbit __signbitf __signbitl argz_next atof atoi atol atoll btowc cimag conj creal feof_unlocked ferror_unlocked fgetc_unlocked fputc_unlocked fstat fstat64 fstatat fstatat64 getc_unlocked getchar getchar_unlocked getline gnu_dev_major gnu_dev_makedev gnu_dev_minor lstat lstat64 mbrlen mknod mknodat pthread_equal putc_unlocked putchar putchar_unlocked stat stat64 strtoimax strtoumax tolower toupper vprintf wcstoimax wcstoumax wctob pgphcQdk9sSf9.pgp Description: PGP signature
Re: toolchain issue makes qt3 drop symbols ?
On dim, fév 10, 2008 at 07:44:02 +, Sune Vuorela wrote: Dear Debian-Devel, we need your advices. Yesterday, we (the qt-kde packagers) uploaded qt3 version 3.3.8b. The biggest differences over 3.3.7 is that it is now also gplv3 licensed. And then this bug report came: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=465028 - libqt3-mt: Missing weak symbols for stat64 functions basically, in qt3 3:3.3.7-9 and earlier, libqt3-mt seems to provide some symbols: $ objdump -T libqt-mt.so.3 | grep stat64 004d2d9e w DF .text 0032 Basestat64 002f19de w DF .text 0032 Basefstat64 005dcba0 w DF .text 0032 Baselstat64 We tracked the issue down. The thing is that libc6 used (before 2.7) to export inline those symbols, whereas now it's only done for C (not C++) and when gcc is = 4.3. The thing is, when not using visiblity=hidden, 'extern inline' emits symbols in the resulting binary. The glibc _was_ wrong before, and it now has the proper behavior. Though, it means that some libraries had stat64 and friends exported in them, and that may cause lot of grief. A list of packages having or using those three symbols are beeing built, I'm unsure about what should be done about them, it's _not_ only qt3 that will have issues here. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpjAKyVu4IHS.pgp Description: PGP signature
Bug#465583: libc6: svn fails on some repositories after ugrade to 2.7-7
On Wed, Feb 13, 2008 at 12:17:23PM +, Jean-Luc Coulon (f5ibh) wrote: Package: libc6 Version: 2.7-6 Severity: grave Justification: renders package unusable Hi, After having upgraded libc6 from 2.7-6 to 2.7-7, I get the following error message on sourceforge or gnome repositories: svn: PROPFIND request failed on '/svnroot/panotools/trunk/libpano' svn: PROPFIND of '/svnroot/panotools/trunk/libpano': Could not resolve hostname `panotools.svn.sourceforge.net': No address associated with hostname (https://panotools.svn.sourceforge.net) please send an `ltrace` output of a working call wiht libc6 2.6-6 and then the same with a failing one with libc6 2.7-7. You'll need libc6-dbg for it to be readable. TIA. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYoYCKzXTRi.pgp Description: PGP signature
Bug#459322: libc6-dev: implementation of pthread_cleanup_pop_restore_np
On Thu, Jan 17, 2008 at 10:43:54AM +, Peter T. Breuer wrote: Also sprach Pierre Habouzit: Checking application/pgp-signature: FAILURE -- Start of PGP signed section. [ Charset UTF-8 unsupported, converting... ] Version: 2.7-6 On mer, jan 16, 2008 at 09:30:12 +, Peter T. Breuer wrote: Here is a simple testcase code which shows up bug libc6-dev: implementation of pthread_cleanup_pop_restore_np .. (is all wrong) It's not according to its author: http://sourceware.org/bugzilla/show_bug.cgi?id=5626 Please bring your problems here if you don't agree. Run the testcase. Read the link I gave. (and please stop this practice of closing a bug when you haven't thought about it or examined the evidence! It is extremely RUDE) It's not rude, upstream thinks it's not a bug and explained why. so I close it as well. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpB0QL6qCmf8.pgp Description: PGP signature
Re: nscd [amd64] now depends on libc6-i386?
On Thu, Dec 27, 2007 at 04:21:01PM +, Anthony DeRobertis wrote: [Please cc me, I'm not subscribed to the list. Hopefully Mutt will set M-F-T correctly.] I notice that the etch4 version of nscd just released in 4.0r2 suddenly depends on libc6-i386. This is on amd64. I couldn't find anything about this using the lists.debian.org search engine, reading the changelog, the stable update doc, or the BTS. Is it just a mistake? this is a known issue of dh_shlibdeps that looks for nscd depends in libc6-i386 because it comes first whereas it's not even from the same $arch, and yields this useless depends. Though it's harmless, so just live with it :) -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpYTNxl9ihDf.pgp Description: PGP signature
Re: nscd [amd64] now depends on libc6-i386?
On Fri, Dec 28, 2007 at 03:25:49PM +, Anthony DeRobertis wrote: On Fri, Dec 28, 2007 at 02:28:26PM +0100, Pierre Habouzit wrote: this is a known issue of dh_shlibdeps that looks for nscd depends in libc6-i386 because it comes first whereas it's not even from the same $arch, and yields this useless depends. Though it's harmless, so just live with it :) Ok, if it's just wasted disk space, I won't worry about it. It's just a rather surprising change to see in a stable update. It's a recurring problem, that occurs randomly, and is a known bug reported on dpkg-dev properly IIRC. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpadD85Mgq9d.pgp Description: PGP signature
Bug#457337: libc6: mremap() returns invalid address
On Fri, Dec 21, 2007 at 09:20:14PM +, Andreas Klöckner wrote:
On Freitag 21 Dezember 2007, Daniel Jacobowitz wrote:
On Fri, Dec 21, 2007 at 12:15:43PM -0500, Andreas Kloeckner wrote:
Breakpoint 1, mmap_resize (m=0x2b6a5b236010, oldp=0x2b6a5bdb4000,
nb=406784) at src/gklib/dlmalloc.c:2358
2358if (cp != CMFAIL) {
So you're here...
2356char* cp = (char*)CALL_MREMAP((char*)oldp - offset,
2357 oldmmsize, newmmsize, 1);
Having just done this...
#define CALL_MREMAP(addr, osz, nsz, mv) ((void)(addr),(void)(osz), \
(void)(nsz), (void)(mv),MFAIL)
Which you said expands to this...
(gdb) p cp
$3 = 0x5bdb4000 Address 0x5bdb4000 out of bounds
So how can this possibly be true, and how does mremap have anything to
do with your problem? Nowhere in this code are you calling it.
I think we need a testcase for this problem, if you are convinced it
has something to do with glibc. Also try strace.
Oops. I pasted the wrong line. CALL_MREMAP is
8
#define CALL_MREMAP(addr, osz, nsz, mv) mremap((addr), (osz), (nsz), (mv))
8
And there is indeed a call to mremap, and it is indeed the last thing the
process does. The strace return value looks ok, but the value that arrives in
C (at least according to gdb and the segfault) is not.
8
...
mremap(0x2ba79d9ef000, 573440, 409600, MREMAP_MAYMOVE) = 0x2ba79d9ef000
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
This strongly looks like a bug in dlmalloc, please read this mremap,
you ask for a _smaller_ map, and in that case, the kernel gives you the
same address, it just removes some pages at the end. I'd say that you
try to read in the old pages that you don't have anymore, and get a
sigsegv. Beware that `p cp` in gdb may yield surprising results in -O2,
especially since:
Breakpoint 1, mmap_resize (m=0x2b6a5b236010, oldp=0x2b6a5bdb4000,
^^
(gdb) p cp
$3 = 0x5bdb4000 Address 0x5bdb4000 out of bounds
^^
mremap(0x2ba79d9ef000, 573440, 409600, MREMAP_MAYMOVE) = 0x2ba79d9ef000
^^
It looks like mremap does what it should, and that for _some_ reason
cp is broken, but according to strace, it's not mremap's fault.
Some printf(%p\n, cp); just after the mremap would help you to debug
probably.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpZBjhXVZ93r.pgp
Description: PGP signature
Bug#456779: glibc: getaddrinfo() sorting broken
On Mon, Dec 17, 2007 at 09:28:36PM +, Julien Cristau wrote: Package: glibc Version: 2.7-3 Severity: important $ getent ahosts ftp.fi.debian.org. 130.230.54.99 DGRAM ftp.fi.debian.org 130.230.54.99 RAW 2001:708:310:54::99 STREAM 2001:708:310:54::99 DGRAM 2001:708:310:54::99 RAW 130.230.54.99 STREAM The 3 INET6 addresses should come first, followed by the INET ones. So that other members of the team don't lose time: julien tested on a 2.6.1-1 and it works, and 2.7-3 is before our patch wrt the CTTE bug, so I'd say it's likely to be an upstream regression. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpBASElZezaw.pgp Description: PGP signature
Bug#443660: New test case for #443660
On Sat, Dec 15, 2007 at 07:35:36PM +, Rémi Denis-Courmont wrote: found 443660 2.7-4 thanks Hello, Seems like the original test case does not crash anymore. I still have problems with this one new though - it crashes pseudorandomly (about 10% crashes here). Unfortunately, I have not been able to reproduce the problem under a debugger. Interestingly, I once had the crash with the first error message in C locale: And FWIW I couldn't reproduce the bug with the latest glibc on am64, but it may be an x86-only issue of course. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpNnf5xgv4Xm.pgp Description: PGP signature
Bug#443660: New test case for #443660
notfound 443660 2.7-4 thanks On Sat, Dec 15, 2007 at 07:35:36PM +, Rémi Denis-Courmont wrote: found 443660 2.7-4 thanks Hello, Seems like the original test case does not crash anymore. I still have problems with this one new though - it crashes pseudorandomly (about 10% crashes here). Unfortunately, I have not been able to reproduce the problem under a debugger. Interestingly, I once had the crash with the first error message in C locale: I completely fail to see why it's the same bug, in fact I'm almost sure it's not. And without a backtrace I'm unsure what we can do about it. Please open a new bug instead of diverting old bugs from their purpose. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpnLcSJ0IlQY.pgp Description: PGP signature
Bug#456531: libc6: strerror_r() not thread-safe
tag 456531 + unreproducible thanks On Sun, Dec 16, 2007 at 01:39:46PM +, Rémi Denis-Courmont wrote: Subject: libc6: strerror_r() not thread-safe Package: libc6 Version: 2.7-4 Severity: important Hello, strerror_r() crashes pseudo-randomly when multiple threads invoke it simultaneously. It appears the problem never occurs when using the C/POSIX locale, and seems to be gettext-related. Test code attached. Interestingly, I once had the crash with the first error message in C locale: # ./a.out Connection timed out Erreur de segmentation # and for the matter I tried the testcase on a i386 and an amd64 and I cannot reproduce the bug, even in 100 runs of your program. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpag7B1bIXb3.pgp Description: PGP signature
Bug#456531: libc6: strerror_r() not thread-safe
On Sun, Dec 16, 2007 at 01:39:46PM +, Rémi Denis-Courmont wrote: Subject: libc6: strerror_r() not thread-safe Package: libc6 Version: 2.7-4 Severity: important Hello, strerror_r() crashes pseudo-randomly when multiple threads invoke it simultaneously. It appears the problem never occurs when using the C/POSIX locale, and seems to be gettext-related. Test code attached. Interestingly, I once had the crash with the first error message in C locale: like said, I'd like to have: * your libc6 version ; * your libc6-i686 version ; * a valgrind trace, gdb is quite useless here. # gdb ./a.out (...) (gdb) run (...) Connexion terminée par Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x86bd0b90 (LWP 10614)] 0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6 #1 0xb7e0d473 in _nl_find_msg () from /lib/i686/cmov/libc.so.6 #2 0xb7e0e122 in __dcigettext () from /lib/i686/cmov/libc.so.6 #3 0xb7e0ceb3 in dcgettext () from /lib/i686/cmov/libc.so.6 #4 0xb7e59ee9 in strerror_r () from /lib/i686/cmov/libc.so.6 #5 0xb7e27c9f in vfprintf () from /lib/i686/cmov/libc.so.6 #6 0xb7e4a874 in vsnprintf () from /lib/i686/cmov/libc.so.6 #7 0xb7e2f1d5 in snprintf () from /lib/i686/cmov/libc.so.6 #8 0x080485f0 in run () #9 0xb7f3a4fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xb7ebe60e in clone () from /lib/i686/cmov/libc.so.6 at least give a bt full or whatever trace that gives line numbers. dcigettext is huge, I won't spot a bug just by reading it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp88uPpMo71b.pgp Description: PGP signature
Bug#443660: New test case for #443660
On Sun, Dec 16, 2007 at 01:30:39PM +, Rémi Denis-Courmont wrote: Le Sunday 16 December 2007 12:58:16 Pierre Habouzit, vous avez écrit : notfound 443660 2.7-4 thanks On Sat, Dec 15, 2007 at 07:35:36PM +, Rémi Denis-Courmont wrote: found 443660 2.7-4 thanks Hello, Seems like the original test case does not crash anymore. I still have problems with this one new though - it crashes pseudorandomly (about 10% crashes here). Unfortunately, I have not been able to reproduce the problem under a debugger. Interestingly, I once had the crash with the first error message in C locale: I completely fail to see why it's the same bug, in fact I'm almost sure it's not. And without a backtrace I'm unsure what we can do about it. Please open a new bug instead of diverting old bugs from their purpose. Connexion terminée par Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x86bd0b90 (LWP 10614)] 0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6 (gdb) bt #0 0xb7e599d8 in strcmp () from /lib/i686/cmov/libc.so.6 #1 0xb7e0d473 in _nl_find_msg () from /lib/i686/cmov/libc.so.6 #2 0xb7e0e122 in __dcigettext () from /lib/i686/cmov/libc.so.6 #3 0xb7e0ceb3 in dcgettext () from /lib/i686/cmov/libc.so.6 #4 0xb7e59ee9 in strerror_r () from /lib/i686/cmov/libc.so.6 #5 0xb7e27c9f in vfprintf () from /lib/i686/cmov/libc.so.6 #6 0xb7e4a874 in vsnprintf () from /lib/i686/cmov/libc.so.6 #7 0xb7e2f1d5 in snprintf () from /lib/i686/cmov/libc.so.6 #8 0x080485f0 in run () #9 0xb7f3a4fb in start_thread () from /lib/i686/cmov/libpthread.so.0 #10 0xb7ebe60e in clone () from /lib/i686/cmov/libc.so.6 Looks like exactly the same problem to me. The trace is the same indeed, could you provide a valgrind trace ? I'm completely unable to reproduce the bug with a glibc 2.7-4. Are you sure youre libc6-686 is a 2.7-4 as well ? But I looked at the code, the section that does the realloc that was responsible for the crash before is properly guarded by mutexes now, so it's definitely (if there still is a crash which atm have no proof about) not occurring at the same place. Hence the valgrind trace that tells line numbers would help a lot. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp6zsgYkcp6v.pgp Description: PGP signature
Bug#456531: libc6: strerror_r() not thread-safe
On Sun, Dec 16, 2007 at 04:21:10PM +, Rémi Denis-Courmont wrote: Le Sunday 16 December 2007 17:55:18 Pierre Habouzit, vous avez écrit : like said, I'd like to have: * your libc6 version ; 2.7-4 * your libc6-i686 version ; 2.7-4 what is your kernel version ? I would be surprised it matters but … It also happens with libc6-i686 purged, in any case, so that's not that: #0 0xb7e31e21 in strcmp () from /lib/libc.so.6 #1 0xb7de5467 in _nl_find_msg () from /lib/libc.so.6 #2 0xb7de6102 in __dcigettext () from /lib/libc.so.6 #3 0xb7de4ea3 in dcgettext () from /lib/libc.so.6 #4 0xb7e32339 in strerror_r () from /lib/libc.so.6 #5 0xb7dffb44 in vfprintf () from /lib/libc.so.6 #6 0xb7e22bc4 in vsnprintf () from /lib/libc.so.6 #7 0xb7e07275 in snprintf () from /lib/libc.so.6 #8 0x080485f0 in run () #9 0xb7f12383 in start_thread () from /lib/libpthread.so.0 #10 0xb7e9663e in clone () from /lib/libc.so.6 * a valgrind trace, gdb is quite useless here. I have tried countless time to reproduce it under valgrind with no results. have you tried helgrind and other race-condition valgrind tools ? at least give a bt full or whatever trace that gives line numbers. dcigettext is huge, I won't spot a bug just by reading it. I have libc6-dbg and that won't do it, what else am I supposed to do? `bt full` instead of just `bt` doesn't shows line numbers ? I'm sorry but I really _can't_ reproduce the problem, whereas I have multi-core machines where race conditions are usually easier to show. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpZlo7ErfdK6.pgp Description: PGP signature
Bug#456531: libc6: strerror_r() not thread-safe
On Sun, Dec 16, 2007 at 08:04:26PM +, Rémi Denis-Courmont wrote: Le Sunday 16 December 2007 21:49:10 Pierre Habouzit, vous avez écrit : what is your kernel version ? I would be surprised it matters but … I started with a self-built vanilla 2.6.23.8, and now using 2.6.22-3-686 from Sid running on a HyperThread single CPU host. Both of them crash. I haven't been able to trigger the problem on amd64. Well I'm still unable to on i386… have you tried helgrind and other race-condition valgrind tools ? I didn't know helgrind was fixed nowadays. Tells this (no crash though): it is since the last release from 4 days ago ;) I'll see with the backtrace if I can find the issue, but I've got nothing so far. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpwRUmO0kVX5.pgp Description: PGP signature
Bug#456260: libc6.1: ldconfig segfault under LANG=ja_JP.eucJP
On Fri, Dec 14, 2007 at 01:51:17AM +, Atsuhito KOHDA wrote: Package: libc6.1 Version: 2.7-3 Severity: important Hi, Subject: Re: Bug#456260: libc6.1: ldconfig segfault under LANG=ja_JP.eucJP ^^^ that should be ja_JB.EUC-JP -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgphtejvD1Gqi.pgp Description: PGP signature
Bug#455974: libc6: Upgrade to libc 2.7-3 breaking of dpkg
On Fri, Dec 14, 2007 at 08:26:35AM +, bluesdog wrote: Similar to the OP, but perhaps somewhat different also. Recent upgrade to libc6 2.7-3 borked dpkg, which then reported libc6 was not completely installed. The error message complained about the /var/lib/dpkg/info/libc6.postinst script, so I renamed the script temporarily, and ran dpkg-reconfigure libc6. On Fri, Dec 14, 2007 at 08:16:14AM +, unknown wrote: After upgrade to libc6 newest version (on a VServer), dpkg refuses to run, also a lot of init scripts, apache and mysql for example, also ps is broken. I'll add a strace for a failing dpkg -l in a followup. Manually wget'ing the etch libc6 and unpacking its data.tar.gz to / resolves the problem, although this is highly unclean. Oo I've rarely seen such useless bug reports, could you _AT LEAST_ say what the error message is ? how are we supposed to fix a problem if the sole thing we know is dang we have a problem. Unless we do have proper informations, we can do nothing but close this bug. Note that if it's another instance of the RHEL 2.6.9 kernel bug, then deal with it, there is nothing we can do about it, see other bugs about that. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpKDmd4hN522.pgp Description: PGP signature
Bug#455603: Suggests or recommends libc6-i686
On Tue, Dec 11, 2007 at 01:53:04AM +, Josh Triplett wrote: Package: libc6 Version: 2.7-4 Severity: wishlist Consider adding a Suggests or Recommends for libc6-i686 to libc6. Suggests would help people find and install it. Recommends might actually make sense, because at this point a pre-686 system might well qualify as an unusual installation per Policy 7.2, and on such a system libc6-i686 will do no harm other than taking up space. Well, debian/control of libc6 is already a mess, I'm not very keen on adding that one. Moreover, linux-image-2.6-686 and higher will pull it already so I'm not sure it's needed here. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpCgx6LXvN13.pgp Description: PGP signature
Re: glibc 2.7-3 MIGRATED to testing causes system to stop starting new programs
On Sun, Dec 09, 2007 at 09:28:06AM +, PieterB wrote: Hello glibc maintainers, I managed to reboot the VPS in repair mode. I see a lot of messages like in /var/log/syslog (example from dovecot, but others programs give errors too): Dec 8 21:18:28 foobar dovecot: child 21837 (login) returned error 127 Dec 8 21:19:28 foobar dovecot: imap-login: imap-login: error while loading shared libraries: /lib/libc.so.6: file too short I manually installed glibc 2.7-4 (libc6_2.7-4_i386.deb) and will reboot after the backup is finished. No that won't work you have to go back to a 2.6 one. Is there anything else I can check to find out what happened? The kernel you run on has a custom redhat patch that conflicts with the new O_CLOEXEC feature. Either they change the kernel, or you keep a pre 2.6. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpTR43m7OBbS.pgp Description: PGP signature
Re: glibc 2.7-3 MIGRATED to testing causes system to stop starting new programs
On Sun, Dec 09, 2007 at 06:28:52PM +, PieterB wrote: On Sun, Dec 09, 2007 at 01:03:01PM +0100, Pierre Habouzit wrote: I manually installed glibc 2.7-4 (libc6_2.7-4_i386.deb) and will reboot after the backup is finished. No that won't work you have to go back to a 2.6 one. I'm restoring a backup. When everything is fixed I'll update my Debian 4.0 testing distribution when my VPS host kernel is compatible with glibc 2.7-4 or later. Is there anything else I can check to find out what happened? The kernel you run on has a custom redhat patch that conflicts with the new O_CLOEXEC feature. Either they change the kernel, or you keep a pre 2.6. I assume you mean pre 2.7 (being 2.6). According to Yean I meant pre 2.6 inclusive actually ;) Can anybody help me find the kernel patch I should ask to be installed (I doubt they do that in short time with a big hosting company like Strato). actually it's a patch to remove (it's called the TUX patch afaict). Can anybody tell me how I can make sure my system doesn't get crashed the next time I do 'apt-get upgrade'? Or should the new patch in glibc-4 prevent problems automatically? hold the glibc. aptitude know how to do that, probably aptitude hold libc6. pgpjihA2PeA1O.pgp Description: PGP signature
Bug#454638: libc6 unusable on kernel 2.6.9 due to opendir/O_CLOEXEC problems
tag 454638 + wontfix Severity 454638 normal thanks On jeu, déc 06, 2007 at 07:42:17 +, H. S. Teoh wrote: Package: libc6 Version: 2.7-3 Severity: grave Justification: renders system (mostly) unusable Nope, that breaks _your_ system, sorry for that, but Debian never released a 2.6.9, etch has 2.6.18 and I just tried, it works fine on it. So we are backward compatible _enough_ to work properly on etch, which is what we want to do. Sorry. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpX2c7iaDBFo.pgp Description: PGP signature
Bug#351469: empty program triggers valgrind, too
.so) ==22198==by 0x400A99D: _dl_new_object (in /lib/ld-2.7.so) ==22198==by 0x40061E4: _dl_map_object_from_fd (in /lib/ld-2.7.so) ==22198==by 0x4008677: _dl_map_object (in /lib/ld-2.7.so) ==22198==by 0x4000C4A: map_doit (in /lib/ld-2.7.so) ==22198==by 0x400DDF5: _dl_catch_error (in /lib/ld-2.7.so) ==22198==by 0x400475F: dl_main (in /lib/ld-2.7.so) ==22198==by 0x4014837: _dl_sysdep_start (in /lib/ld-2.7.so) ==22198==by 0x400230A: _dl_start (in /lib/ld-2.7.so) ==22198==by 0x4000A67: (within /lib/ld-2.7.so) ==22198== ==22198== Conditional jump or move depends on uninitialised value(s) ==22198==at 0x400B08F: _dl_relocate_object (in /lib/ld-2.7.so) ==22198==by 0x4003C16: dl_main (in /lib/ld-2.7.so) ==22198==by 0x4014837: _dl_sysdep_start (in /lib/ld-2.7.so) ==22198==by 0x400230A: _dl_start (in /lib/ld-2.7.so) ==22198==by 0x4000A67: (within /lib/ld-2.7.so) ==22198== ==22198== Conditional jump or move depends on uninitialised value(s) ==22198==at 0x400B09C: _dl_relocate_object (in /lib/ld-2.7.so) ==22198==by 0x4003C16: dl_main (in /lib/ld-2.7.so) ==22198==by 0x4014837: _dl_sysdep_start (in /lib/ld-2.7.so) ==22198==by 0x400230A: _dl_start (in /lib/ld-2.7.so) ==22198==by 0x4000A67: (within /lib/ld-2.7.so) ==22198== ==22198== ERROR SUMMARY: 8 errors from 8 contexts (suppressed: 0 from 0) ==22198== malloc/free: in use at exit: 0 bytes in 0 blocks. ==22198== malloc/free: 0 allocs, 0 frees, 0 bytes allocated. ==22198== For counts of detected errors, rerun with: -v ==22198== All heap blocks were freed -- no leaks are possible. Maybe this is an amd64 issue only? Best regards Uwe -- System Information: Debian Release: 4.0 APT prefers stable APT policy: (900, 'stable'), (300, 'testing-proposed-updates'), (300, 'testing'), (200, 'unstable'), (2, 'experimental'), (1, 'proposed-updates') Architecture: amd64 (x86_64) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.22-3-amd64 Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Versions of packages libc6 depends on: ii libgcc1 1:4.2.2-3 GCC support library libc6 recommends no packages. -- debconf information: glibc/restart-failed: glibc/restart-services: -- Uwe Kleine-König, Software Engineer Digi International GmbH Branch Breisach, Küferstrasse 8, 79206 Breisach, Germany Tax: 315/5781/0242 / VAT: DE153662976 / Reg. Amtsgericht Dortmund HRB 13962 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpDRIX2iHuPQ.pgp Description: PGP signature
Bug#454266: upgrade to 2.7 fails, leaving system unusable
On Tue, Dec 04, 2007 at 02:53:05PM +, Marcus Better wrote: Could you provide an md5sum (or any non too trivial checksum) of /lib/i686/cmov/libc.so.6 ? 76e00ba611b3bcb7827bd3f4e3b4930f /lib/i686/cmov/libc.so.6 this looks rotten, on a machine I have access to (an i386): $ dpkg -l libc6-i686 ii libc6-i6862.7-3 [...] $ md5sum /lib/i686/cmov/libc.so.6 d19b755e688eca788ec8126f3634d419 /lib/i686/cmov/libc.so.6 have you libc6-i686 installed ? which version ? could you try to reinstall it from scratch ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgphYWBU3XeCD.pgp Description: PGP signature
Bug#454266: upgrade to 2.7 fails, leaving system unusable
On Tue, Dec 04, 2007 at 12:57:14PM +, Marcus Better wrote: Pierre Habouzit wrote: Could you touch /etc/ld.so.nohwcap and see if it looks like that fixes your system ? Yes, that fixes it! okay so there is an issue with the optimized version of the library. touching /etc/ld.so.nohwcap tells the linker to avoid the use of optimized libraries. Attempting the upgrade again makes the problem re-appear, and the upgrade fails with the following messages: Setting up libc6 (2.7-3) ... dpkg[3484]: segfault at eip b7d71f6d esp bfb11cfc error 4 /var/lib/dpkg/info/libc6.postinst: line 357: 3484 Segmentation fault dpkg --compare-versions $preversion lt 2.3.5-1 and two more segfaults in iconvconfig and update-rc.d. hmmm it looks a lot like #397020 that I thought was changed upstream, so maybe not. On Tue, Dec 04, 2007 at 12:58:32PM +, Marcus Better wrote: Aurelien Jarno wrote: That looks ok. Which kernel are you using? 2.6.24-rc3 when it broke, but using 2.6.23 didn't help. Both are self-compiled. are you using pax execshield or anything like that ? Given that you maintain it I suppose you do. If yes, could you please try with a stock debian kernel ? If it's because execshield then we'll downgrade the bug to important so that the libc can migrate, and as soon as it migrated we'll rework the patch used for #397020 and reinclude it. Cheers, pgpuBYlQeb22P.pgp Description: PGP signature
Bug#452664: Can't upgrade libc6 in cowbuilder
reassign 452664 cowdancer thanks On Sat, Dec 01, 2007 at 03:27:35PM +, Bas Zoetekouw wrote: Hi Pierre! You wrote: When I tried to upgrade my cowbuilder environment (i386 env on amd64), I got this error: you do that using linux32 ? (I don't think it matters much but who knows...). Could you also try to reproduce that in a simple deboostrapped chroot to see if the cowbuilder LD_PRELOAD isn;'t the culprit ? This bug is starting to look more and more like a Heisenbug. Upgrading libc6 only fails about half of the time, but other packages (tzdata for example) also fail sometimes with similar out of memory errors: etting up tzdata (2007i-2) ... cowdancer: unexpected WIFEXITED status in waitpid /var/lib/dpkg/info/tzdata.postinst: line 29: /etc/timezone: Cannot allocate memory dpkg: error processing tzdata (--configure): subprocess post-installation script returned error exit status 1 Errors were encountered while processing: tzdata E: Sub-process /usr/bin/dpkg returned an error code (1) However, the bug goes away if I unset the libcowdancer.so LD_PRELOAD, I guess that's where the problem is in. Some more debugging shows that the errors occors in the call to debconf: + PERL_DL_NONLAZY=1 ++ export PERL_DL_NONLAZY ++ '[' '' ']' ++ exec /usr/share/debconf/frontend /var/lib/dpkg/info/libc6.postinst configure 2.7-3 cowdancer: unexpected WIFEXITED status in waitpid /var/lib/dpkg/info/libc6.postinst: line 142: /etc/ld.so.conf: Cannot allocate memory So, I guess this really is a bug in cowdancer, although I have no idea what the problem could be. hmm probably. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpcAIiClbU0h.pgp Description: PGP signature
Bug#452664: Can't upgrade libc6 in cowbuilder
On Sat, Nov 24, 2007 at 12:35:23PM +, Bas Zoetekouw wrote: Package: libc6 Version: 2.6.1-6 Severity: important When I tried to upgrade my cowbuilder environment (i386 env on amd64), I got this error: you do that using linux32 ? (I don't think it matters much but who knows...). Could you also try to reproduce that in a simple deboostrapped chroot to see if the cowbuilder LD_PRELOAD isn;'t the culprit ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp8dPo8t9Kpc.pgp Description: PGP signature
Bug#452081: makedb broken on alpha/sid
On Tue, Nov 20, 2007 at 09:56:37AM +, Peter Palfrader wrote: Package: libc6.1 Version: 2.6.1-6 Severity: important Hi, In the sid chroot of albeniz.debian.org, an alpha machine, makedb cannot build the passwd database: albeniz:~# strace -f chroot /srv/albeniz.debian.org/chroot/sid makedb /var/lib/misc/albeniz.debian.org/passwd.tdb -o /var/lib/misc/passwd.db.t would it be possible to have a more useful ltrace instead please ? (with libc6-dbg installed). We believe it has something to do with a glob fix in the glibc. A ltrace of a working makedb and a broken one would be much appreciated, thanks. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgphHZjuQewDC.pgp Description: PGP signature
Bug#451886: fgets() and poison NULL byte attacks (aka NULL escapes)
tag 451886 + wontfix thanks On Mon, Nov 19, 2007 at 05:16:29AM +, Andrew Buckeridge wrote: package: libc6 version: 2.3.6.ds1-13etch2 severity: wishlist Possible partial fix for fgets and alternatives. Bug #57729 is marked as done. It could be fixed for real. I have found null escapes a pretty reliable way of breaking many C programs including various editors. The standard C stdio.h fgets function is just plain wrong. fputs stops at a '\0', but fgets may only stop at '\n' even if a '\0' is encountered. There is no way of knowing how much is read by fgets. These functions are inconsistent and are not binary safe. The standard should be fixed. The libc will follow the standard, and the standard will never ever fix things like that. If you're going to read binary data, indeed, you should not use FILE* or fgets, but plain read(1) calls with non blocking sockets in a select loop. Anyway, the glibc _packaging_ team will never ever take the liberty to introduce new symbols that arent in the upstream glibc, it would be way too disruptive, so please bring this upstream, we don't have the resources to do that for you. and yes btw fputs stops at the first \0 because it puts a string, and strings in C are NUL terminated. fgets has a disruptive API, and _yes_ I would very much prefer that fgets had this API intead of the current: ssize_t fgets(char *buf, size_t len); with the usual semantics that -1 means error (with errno set properly), and else the return value would be the amount of bytes written in the buffer buf, not counting the last '\0', meaning that the return value would be at most equal to len - 1. Or even name this fgetline as it's what it does for real. Sadly it's not the case, blame the C committee. Meanwhile I'm leaving that bug as wontfix. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpMF37SIgwGb.pgp Description: PGP signature
Re: Glibc Installation
On Tue, Nov 13, 2007 at 03:30:13AM +, James Mathis wrote: Hello, There seems to be some contradiction within the Install doc and FAQs concerning the install location of glibc. One document indicates it's safe to install at '/usr/local' and another document indicates it's not. The same applies to the '/usr' directory. Which is it? Anyway, say I install to '/usr/local/gblic2' and I want my gcc compiler to use the gblic2 library. Do I just add this path to LD_LIBRARY_PATH or are there other things that must be done. Appreciate any additional information. Thanks What are you talking about ?! This list is about Debian glibc packaging. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWgwBktkMfU.pgp Description: PGP signature
Bug#449423: glibc2.7 follow-up
On Tue, Nov 06, 2007 at 12:24:55AM +, Stuart Prescott wrote: For further information, see http://lists.debian.org/debian-devel/2007/11/msg00033.html And ? What does it proves ? As a member of the glibc packaging team I quite know what I'm saying. Locales from glibc 2.7 aren't installable, bummer. It doesn't prevents you to install any other debian package as none depends upon glibc 2.7 (or that's a bug in them). This is a temporary situation, please live with it. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSf6uBXe15C.pgp Description: PGP signature
Bug#449423: glibc2.7 followup
On Tue, Nov 06, 2007 at 02:11:23PM +, Stuart Prescott wrote: And ? What does it proves ? As a member of the glibc packaging team I quite know what I'm saying. I know that you know that -- that comment wasn't for you but for the original reporter and anyone else who might (like I did) waste considerable time trying to work out what was wrong with the locales package. I eventually found the above explanation of what was going on. There is a /usr/share/bug/locales/presubj to explain that, and a NEWS.Debian or a README.Debian, so I feel like closing the bug without more ado appropriate. The reporter used reportbug, hence saw that, and didn't read. Not my fault. Locales from glibc 2.7 aren't installable, bummer. It doesn't prevents you to install any other debian package as none depends upon glibc 2.7 (or that's a bug in them). Actually, it is causing problems in pbuilders -- this is a default pbuilder install within etch of a sid chroot. For example: sun-java6-jdk depends on sun-java6-jre sun-java6-jre depends on locales locales in sid is 2.7-0exp6 and depends on glibc-2.7-1 glibc-2.7-1 is not installable. Therefore, sun-java6-jdk is not installable. There are a lot of packages that depend on locales and if locales is not installable within a chroot, then those packages are also not installable. If you believe this is an incorrect dependency, then there are quite a few bugs that need filing. Pulling the locales package from lenny would solve this problem, but that seems somehow dirty. I guess an existing pbuilder would probably also continue as it could just use an older locales to work and that it's just new chroots that are broken. I know there are issues for people that don't have etch sources in their autobuilder/chroot/whatever. Though adding etch sources will allow you to build packages. You also can use my setup to inject a directory of .debs as usable debs (see http://madism.org/~madcoder/dotfiles/ the pbuilder ones) and just drop working locales and so on in there, it should just work). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpQ4XmB5xqxn.pgp Description: PGP signature
Re: tzdata conflict under Ubuntu
hint: To: [EMAIL PROTECTED] ^^ On Fri, Nov 02, 2007 at 06:47:36PM +, Customer Service wrote: Libc6 package fails to install due to a 'conflist with tzdata' under Ubuntu.. Is there any workaround? Thanks. go ask Ubuntu people please. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpVN5d8wDVq4.pgp Description: PGP signature
glibc-prof
I discussed about this with Aurélien quickly on IRC today, but that's an issue that I've been thinking about for some time. We currently build a flavor of the libc with profiling support. With tools like oprofile and the libc6-dbg package, the need for is is definitely smaller than before. gprof is less accurate for timings, but more accurate to count real number of times a function was called. Though I believe that people wanting to do that usually care aboute _their_ code, and not really aboute the libc itself. My point is that libc6-prof isn't terribly useful nowadays, and that it's probably accountable for 25 to 33% of the libc build time (not the test-suite though), which is probably a nice time save to make. I'd like to know what you people think, and I'll probably pop that question on -devel@ if enough of us believe this package indeed has leass meaning and could go away. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpZ1ZupLThCI.pgp Description: PGP signature
Bug#447609: ldconfig triggerisation
On Mon, Oct 22, 2007 at 06:28:23PM +, Joey Hess wrote: Couldn't file triggers be used, so ldconfig is triggered after any package installs a library file? That's much more how I expected triggers to be used, rather than needing an ugly ldconfig wrapper. I think it also addresses drow's point about libraries in nonstandard locations, since those packages could just run ldconfig as usual. Meanwhile, packages installing libraries to standard locations could stop calling ldconfig. I second that. This is way better indeed. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpWKyLFMNBD7.pgp Description: PGP signature
glibc 2.7
Hi, Glibc upstream announced recently that the glibc 2.7 will be tagged and released very soon (probably on Oct 17[0]). This release (for what I've seen) has a lot of bugfixes (on nscd, locales, and many issues we reported in Debian). It also has the stubs to use eventfd's and timerfd's (new linux system calls). We initially thought this release would happen a lot later, and weren't sure that we could even contemplate the idea of packaging it for lenny. It seems it may change. I'm hence warning that the glibc team is considering (given enough testing in experimental) pushing a 2.7 glibc for lenny. This is not for tomorrow, but I prefer to warn so that the release team can anticipate things. I hope that we will be able to begin glibc 2.7 uploads (in experimental) during November, depending on how well the builds will work (or even build) we will be able to have more insight on a date for an unstable upload. Cheers, [0] http://sourceware.org/ml/libc-alpha/2007-10/msg00010.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp6e6qE6e2hO.pgp Description: PGP signature
Re: glibc 2.7
On Mon, Oct 08, 2007 at 08:16:59AM +, Matthias Klose wrote: Glibc upstream announced recently that the glibc 2.7 will be tagged and released very soon (probably on Oct 17[0]). which toolchain versions are required as build dependencies? AFAICT it should be basically the same as glibc 2.6. But I haven't looked at it very deeply either yet. The big step was the migration to NPTL that happened a few releases ago, that needed a quite recent kernel on many platforms, but I don't think glibc2.7 needs anything new. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoLSvF9s9Fn.pgp Description: PGP signature
Bug#445210: closed by Pierre Habouzit [EMAIL PROTECTED] (Re: Bug#445210: libc6: glob(3) doesn't treat \ correctly)
forwarded 445210 http://sourceware.org/bugzilla/show_bug.cgi?id=5103
severity 445210 minor
thanks
On Thu, Oct 04, 2007 at 08:44:24AM +, Herbert Xu wrote:
reopen 445210
quit
On Thu, Oct 04, 2007 at 08:27:04AM +, Debian Bug Tracking System wrote:
and the test case on http://sourceware.org/bugzilla/show_bug.cgi?id=3996
works
as well.
Please check your environment, the libc works.
There were other tests in the bug report.
Wonderful, next time please bother pointing to the one that fails
directly, that helps avoid losing time.
$ cat a.c
#include glob.h
#include stdio.h
int main() {
glob_t pglob;
printf(%d\n, glob(\\/*, 0, 0, pglob));
printf(%d\n, glob(/*, 0, 0, pglob));
return 0;
}
$ make a
cc a.c -o a
$ ./a
3
0
FWIW it seems that the remaining issue is with patterns of the form:
\\/ followed by any globbing char (*, ?, ...). Else I've not been
able to make it fail. As in that case \\ is definitely not significant,
I've lowered the severity.
Cheers,
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpnI0bxU7OXX.pgp
Description: PGP signature
Re: getaddrinfo() behaviour
On Tue, Oct 02, 2007 at 08:37:42AM +, Florian Weimer wrote: * Anthony Towns: Updating the proposed standard has not been tried. Just to give you an idea of the time scale involved: moving RFC 3484 to HISTORIC (which is the most likely result, at least for the Rule 9 part) will take at least a year. So let's try early ? -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpBIrflgPd1C.pgp Description: PGP signature
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
On Sat, Sep 29, 2007 at 09:56:35AM +, Wolf Wiegand wrote: Hi, Kurt Roeckx wrote: I haven't seen anybody claim that any of the *BSDs implemented rule 9 that also says he tested it, I've only seen reported of FreeBSD saying it didn't. I just tested this: ~/ uname -sr FreeBSD 6.2-STABLE ~/ ping -c 1 ftp.us.debian.org | grep PING PING ftp.us.debian.org (204.152.191.7): 56 data bytes ~/ ping -c 1 ftp.us.debian.org | grep PING PING ftp.us.debian.org (35.9.37.225): 56 data bytes rather use sth similar than: $ getent ahosts ftp.us.debian.org I'm not sure if BSDs know about ahost though. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSHkMuyM1Uw.pgp Description: PGP signature
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
On ven, sep 28, 2007 at 05:21:59 +, Ian Jackson wrote: Pierre Habouzit writes (Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch): But such a ruling in Debian (disregarding Debian's internal power games) has a pretty limited scope, and won't fix the fact that most OSes follow Rule 9 and that people that use Debian on their servers will still need to use other techniques than DNS RR until total world domination is achieved. Well, it will allow Debian's own ftpmasters to use DNS round robin because nearly all of the systems which access ftp.*.debian.org are running Debian. Yeah, that allows pretty only that. I mean, any other service running on a Debian won't benefit from this. I don't say it's not worth it either, I just say it's fixing at the wrong level. Also note that patching the 3 apt calls to getaddrinfo to do real round robin is maybe 10 lines of C, and would have solved apt mirrors issues on every OS that uses apt (yeah not only Debian uses apt). DNS RR is broken on Windows XP since SP2, Windows Vista, most *BSDs, Redhat and Fedora, and probably any Linux distribution out there (including Ubuntu LTS…). Okay it's nice to be a righteous citizen, but I'm not sure that fighting like you did on the CT list was worth the effort. Service administrators (Debian systems included) will need to stop using DNS RR right now, because it won't work with too many systems anymore. Is that an issue ? I believe it is. But blame the IETF, harrass them. Oh and above anything else I find really intriguing that such a bad functionality (at least it seems to be a pretty grave problem given the length of some mails on the CT list) has slept in Debian for more than 2 years unnoticed. AIUI it was noticed by the ftpmasters when ftp.us.debian.org broke when large numbers of users upgraded to etch and got the new behaviour. Well, I began to hear those rumors only now, and I'm surprised that stable users have such an impact on ftpmaster, wrt e.g. unstable users (and unstable users have the issue for 2 years). This argument is pure crap and prevent anyone interested to post to the TC list. This has pissed me beyond repair on this problem, and I believe I wasn't the only one. IMHO, the TC isn't functional with a restricted mailing list. debian-release is not under the same censorship, and looks though pretty functional to me. I'm sorry you don't like the way we run our mailing list but that is a matter for us. I'm sorry, but the CT is a _Debian_ committee, composed of delegates, and how it works is a matter to the whole project. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSG3WLASU5w.pgp Description: PGP signature
Re: getaddrinfo: DNS round robin vs RFC3484 s6 rule 9, for etch
On Fri, Sep 28, 2007 at 07:24:44PM +, Andreas Barth wrote: * Pierre Habouzit ([EMAIL PROTECTED]) [070928 21:08]: DNS RR is broken on Windows XP since SP2, Windows Vista, most *BSDs, Redhat and Fedora, and probably any Linux distribution out there I was told it isn't broken on Fedora. That's not what the glibc CVS says, and given Uli's position about the new behavior of getaddrinfo I would be *very* surprised. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpi3Es5Kr5Hp.pgp Description: PGP signature
Bug#443660: libc6: dgettext not thread-safe
On Sun, Sep 23, 2007 at 08:15:45AM +, Rémi Denis-Courmont wrote:
#include stdio.h
#include pthread.h
#include locale.h
#include libintl.h
static void *run (void *dummy)
{
(void)dummy;
for (;;)
printf (Translation code: %s\n, dgettext(vlc, C));
}
int main (void)
{
unsigned i;
setlocale (LC_ALL, );
bindtextdomain (vlc, /usr/share/locale);
pthread_t threads[300];
for (i = 0; i sizeof (threads) / sizeof (threads[0]); i++)
pthread_create (threads + i, NULL, run, NULL);
run (NULL);
return 0;
}
When the problem occurs under valgrind, it complains:
==3535== Thread 3:
==3535== Invalid read of size 4
This is probably because of a speculative strcmp (libc sometimes reads
outside the string because it knows it can).
==3535==at 0x4063F0B: _nl_find_msg (dcigettext.c:862)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
==3535== Address 0x418C91C is 0 bytes after a block of size 12 alloc'd
==3535==at 0x4024862: realloc (vg_replace_malloc.c:306)
==3535==by 0x4063FF1: _nl_find_msg (dcigettext.c:876)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
This one though looks fishy.
There appears to be a similar issue with strerror_r() also.
Have you looked at the code ? I can tell it's thread safe, except that
it calls _(Unknown error) at some point, which would indicate to be
the same bug as yours, the rest is definitely thread safe.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpXr9wjV6uMv.pgp
Description: PGP signature
Bug#443660: libc6: dgettext not thread-safe
On Sun, Sep 23, 2007 at 10:37:59AM +, Rémi Denis-Courmont wrote:
Le Sunday 23 September 2007 12:15:31 Pierre Habouzit, vous avez écrit :
On Sun, Sep 23, 2007 at 08:15:45AM +, Rémi Denis-Courmont wrote:
#include stdio.h
#include pthread.h
#include locale.h
#include libintl.h
static void *run (void *dummy)
{
(void)dummy;
for (;;)
printf (Translation code: %s\n, dgettext(vlc, C));
}
int main (void)
{
unsigned i;
setlocale (LC_ALL, );
bindtextdomain (vlc, /usr/share/locale);
pthread_t threads[300];
for (i = 0; i sizeof (threads) / sizeof (threads[0]); i++)
pthread_create (threads + i, NULL, run, NULL);
run (NULL);
return 0;
}
When the problem occurs under valgrind, it complains:
==3535== Thread 3:
==3535== Invalid read of size 4
This is probably because of a speculative strcmp (libc sometimes reads
outside the string because it knows it can).
==3535==at 0x4063F0B: _nl_find_msg (dcigettext.c:862)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
==3535== Address 0x418C91C is 0 bytes after a block of size 12 alloc'd
==3535==at 0x4024862: realloc (vg_replace_malloc.c:306)
==3535==by 0x4063FF1: _nl_find_msg (dcigettext.c:876)
==3535==by 0x4064A41: __dcigettext (dcigettext.c:639)
==3535==by 0x4063972: dcgettext (dcgettext.c:53)
==3535==by 0x406399F: dgettext (dgettext.c:54)
==3535==by 0x80484DD: run (in /home/remi/a.out)
==3535==by 0x402D2D2: start_thread (pthread_create.c:296)
==3535==by 0x41124ED: clone (in /usr/lib/debug/libc-2.6.1.so)
This one though looks fishy.
It's the same error! It only means that _nl_find_msg from dcigettext.c:862
tries to read at an address right after the end of a realloc() done at line
876 in the same file, as far as I understand.
yes, speculative is that. As libc knows that memory can be read
outside from an allocated block as soon as you don't go after the end of
a page, it sometimes reads outside from the buffer to be able to compute
lengths of strings or string comparisons, so I wouldn't care a lot. THe
second block _is_ probably the issue, because the realloc could be
performed in many thread at a time, hence corrupt the struct. I already
reported the bug upstream, we'll see what Uli will say.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpCq79Eqa9sw.pgp
Description: PGP signature
Bug#442247: Bug#442250: [PHP-DEV] CVE-2007-4840
tag 442250 + wontfix
thanks
On Tue, Sep 18, 2007 at 09:48:55PM +, sean finney wrote:
iconv_t
iconv_open (const char *tocode, const char *fromcode)
{
char *tocode_conv;
char *fromcode_conv;
size_t tocode_len;
size_t fromcode_len;
__gconv_t cd;
int res;
/* Normalize the name. We remove all characters beside alpha-numeric,
'_', '-', '/', '.', and ':'. */
tocode_len = strlen (tocode);
tocode_conv = (char *) alloca (tocode_len + 3);
=
so it's not surprising that big strings could end up being problematic...
OTOH the caller should check those are likely charsets. I mean calling
iconv_open with strhings that are longer than a few octets is completely
silly. The longest charset the libc recognize is 22 chars long, 32 if
you append //TRANSLIT to it.
mallocing for that is completly silly, and the caller should do some
basic sanitizing first.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpPAaR4kjGGb.pgp
Description: PGP signature
Bug#442858: libc6-prof: programs linked agains libc_p.a crash with a SEGV
found 442858 2.6.1-1 tag 442858 + confirmed thanks It's already present in lenny, don't block migrations because of that. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpbXE1SWEN6Z.pgp Description: PGP signature
Re: glibc's getaddrinfo() sort order
On Thu, Sep 13, 2007 at 12:14:09AM +, Anthony Towns wrote: On Thu, Sep 13, 2007 at 12:06:40AM +0100, Ian Jackson wrote: Does anyone have an answer to my point that application of rule 9 changes the long-established meaning of existing DNS data ? I'm not familiar with how getaddrinfo() has been implemented in the past -- but I think it makes more sense to look at the definition of the function than the data it's manipulating. The RFC tries to make getaddrinfo return a predictable ordering in the face of random orderings from DNS. That seems a perfectly reasonable way to define a function in the abstract; though certainly the ordering it comes up with can be criticised. I disagree with your answer to that first question. gethostbyname returns results in random order. getaddrinfo should do the same. I'd say it's more important that getaddrinfo() on Debian behave the same as on other operating systems, than that it behave in the same way as other functions. I can only take the RFC's assertion as to getaddrinfo()'s proper behaviour though; I don't have a more direct idea how getaddrinfo() behaves in previous versions of Debian, other Linux distros, other libcs, Windows, etc. Our tests shows that windows XP since SP1 (or 2 ?), vista, various recent BSD, and now glibc 2.6 (or 2.5 I don't remember when it was introduced) all behave this way. I've no access to macos X, but I wouldn't be surprised it works the same. Another interesting hint would be to test on solaris too. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpY7UGvlzQJV.pgp Description: PGP signature
Re: glibc's getaddrinfo() sort order
On ven, sep 07, 2007 at 07:15:42 +, Pierre Habouzit wrote:
On Thu, Sep 06, 2007 at 11:46:54PM +, Joey Hess wrote:
Pierre Habouzit wrote:
Also note that probably many many Windows machines work that way (the
RFC was written by a MS guy). And this behaviour impacts software
developpers, and people that hoped that having multiple A records for
their service will see a perfect round robin will be stuck anyways. I
mean, it's non previous-practice-backward-compliant and one can argue
reasonably it sucks. But hel-llooo ! this kind of design choice is not
only local. If every one (or the majority) on the internet behaves like
this, fixing this bug (if it is really one) in Debian will _not_, I
say _not_ prevent us from fixing many software that rely on DNS round
robin, because OTHER PARTIES will use the RFC-foo algorithm, and WE will
have to cope with that whatever choice is made.
On that matter, according to Aurélien, Vista (maybe XP),
{Open,Net,Free}BSD follow the RFC. Other OSes could be tested (MacOS X
and solaris come to mind). So it's kind of a decision of Debian vs. the
rest of the world. And if I don't really care about the issue of the
decision technically, this aspect worries me.
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpCalQfmLsOJ.pgp
Description: PGP signature
Re: glibc's getaddrinfo() sort order
On ven, sep 07, 2007 at 07:45:52 +, Pierre Habouzit wrote:
On ven, sep 07, 2007 at 07:15:42 +, Pierre Habouzit wrote:
On Thu, Sep 06, 2007 at 11:46:54PM +, Joey Hess wrote:
Pierre Habouzit wrote:
Also note that probably many many Windows machines work that way (the
RFC was written by a MS guy). And this behaviour impacts software
developpers, and people that hoped that having multiple A records for
their service will see a perfect round robin will be stuck anyways. I
mean, it's non previous-practice-backward-compliant and one can argue
reasonably it sucks. But hel-llooo ! this kind of design choice is not
only local. If every one (or the majority) on the internet behaves like
this, fixing this bug (if it is really one) in Debian will _not_, I
say _not_ prevent us from fixing many software that rely on DNS round
robin, because OTHER PARTIES will use the RFC-foo algorithm, and WE will
have to cope with that whatever choice is made.
On that matter, according to Aurélien, Vista (maybe XP),
{Open,Net,Free}BSD follow the RFC. Other OSes could be tested (MacOS X
and solaris come to mind). So it's kind of a decision of Debian vs. the
rest of the world. And if I don't really care about the issue of the
decision technically, this aspect worries me.
Still one technical point, here is the excerpt from the RFC on the
offending rule:
Rule 9: Use longest matching prefix.
When DA and DB belong to the same address family (both are IPv6 or
both are IPv4): If CommonPrefixLen(DA, Source(DA))
CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if
CommonPrefixLen(DA, Source(DA)) CommonPrefixLen(DB, Source(DB)),
then prefer DB.
What it means is that for IPs with the same common prefix, the order
of the address is unchanged wrt how it came up in the DNS answer.
What it means, is that when I use apt to fetch from ftp.debian.org
from my home ISP (proxad) it takes the mirror that proxad does
(ftp.fr.d.o). When I go to my parents, using wanadoo (now Orange), it
picks the Oleane one (ftp.fr2.d.o) which indeed is nearer. It makes
completely sense.
And as per rule of the common prefix, on a local network, RR still can
be assumed on a given VLAN. It actually makes quite some sense to me.
Maybe that's why Joey Hess had variability: the RFC does not specify a
*full* ordering, it just aim to restrict the RR to the nearest
servers to the client.
Of course, usualy ISP IP's have first octet smaller than 127, so if
you host a service with RR on a network with the first octet greater
than 128 and a mirror on an IP with a first octet smaller than 128, the
client of your service from the ISP will never chose the former because
of this rule. This is a RFC that favors people with large mirroring
networks for their service, and hinders people with small mirroring
networks because they have to chose the IP for their network servers
with care.
I think I've described everything important for the Ctte to rule this,
so unless a question pop up, I'll let you rule in peace :)
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpfigLMJUEPw.pgp
Description: PGP signature
Re: glibc's getaddrinfo() sort order
On Thu, Sep 06, 2007 at 11:46:54PM +, Joey Hess wrote: Pierre Habouzit wrote: The point is, there is an RFC, and we put a patch so that admins can disable it using gai.conf. There is an RFC is not always a good excuse for breaking existing systems. Admins can disable it is not a good argument when one common class of the breakage is all the systems that _don't_ disable it hammering systems that have round-robins set up to distribute load. More generally, we added an option so your bug is fixed is a common fallacy. The point is: the option is here, I don't really care if the Ctte decides to set true or false by default. My underlying point was just that the switch is easy for us. SO yeah, if we change the default option, the bug is definitely fixed and is anything but a fallacy. OTOH there is no way upstream will change that (Ulrich refused the patch with blatant aggressiveness), so every other distribution (Fedora and RedHat, probably many other) will work that way. So we can rule everything we want here (and I absolutely don't care about the issue of the decision, I was just giving some pointers to the pro's as I assumed that the cons were obvious to anyone), this will not change how upstream glibc works, so many people (probably a majority ?) will use this new scheme anyway. And I also say that knowing Uli, (and knowing how deeply I care about this issue ;p) I won't spend a minute trying to argue with Uli, I'm not insane, and don't have the man-years to do that. Also note that probably many many Windows machines work that way (the RFC was written by a MS guy). And this behaviour impacts software developpers, and people that hoped that having multiple A records for their service will see a perfect round robin will be stuck anyways. I mean, it's non previous-practice-backward-compliant and one can argue reasonably it sucks. But hel-llooo ! this kind of design choice is not only local. If every one (or the majority) on the internet behaves like this, fixing this bug (if it is really one) in Debian will _not_, I say _not_ prevent us from fixing many software that rely on DNS round robin, because OTHER PARTIES will use the RFC-foo algorithm, and WE will have to cope with that whatever choice is made. BTW, I'm seeing some programs that use getaddrinfo and still don't have the RFC 3484 sorting behavior. Is this controlled by the AI_ADDRCONFIG flag? TTBOMK it's a bug wrt intended behaviour as per upstream. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpf1lydUiqh6.pgp Description: PGP signature
Re: glibc's getaddrinfo() sort order
On Thu, Sep 06, 2007 at 10:04:23PM +, Kurt Roeckx wrote: Hi, I'm not agreeing with the glibc maintainer(s) about wether getaddrinfo() should sort the results or not. I think the current way it sorts things does not work at all in IPv4, and I think it hurts more than it does good. I'm seeking input from the tech-ctte on how to handle this. The point is, there is an RFC, and we put a patch so that admins can disable it using gai.conf. Note also that old calls like gethostbyname still return address randomly. It's somehow accepted that people using getaddrinfo should be aware of the RFC requirements wrt orderings, and that applications for whose DNS resolutions round robins may matter should implement their own randomization. the Ctte may want to read: - http://udrepper.livejournal.com/16116.html - http://people.redhat.com/drepper/linux-rfc3484.html -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpXomHNkLCZ5.pgp Description: PGP signature
Bug#385704: follow-up on oprofile/libc6-dbg(amd64)
On Thu, Aug 30, 2007 at 12:45:54AM +, Junichi Uekawa wrote: Hi, I'm still seeing that oprofile cannot use libc6-dbg. Anyone seeing the same problem? it's an issue with oprofile that needs to be rebuilt and have a versionned dependency on recent binutils. There is an open RC bug about that, and if the maintainer does not fixes it, I'm going to NMU it as I say in the bugreport (the oprofile one). Note that it has nothing to do with the libc6-dbg issue amd64 (and other archs) had, it's an oprofile issue only. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpL54xhNetmO.pgp Description: PGP signature
Bug#438179: [EMAIL PROTECTED]: Re: [PATCH] getaddrinfo(): option to not sort IPv4 addresses]
On Mon, Aug 20, 2007 at 10:15:03PM +, Kurt Roeckx wrote: The reason we have that sorting is to get consistency. I won't add such an option to disturb it. Not to sort is completely, utterly wrong since the order in which addresses are returned from the service are more or less random. The random order is exactly the point in the first! Nameservers even return a different one as first specially to get such behaviour. Please argue that with Uli directly. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpiDpoXu9yg5.pgp Description: PGP signature
Bug#435382: libc6: ld-linux.so segfault.
On Tue, Jul 31, 2007 at 11:57:23AM -0400, Daniel Jacobowitz wrote: On Tue, Jul 31, 2007 at 07:25:23PM +0400, Sergei Organov wrote: 4. Probably ld-linux.so itself should not segfault no matter what. Thank you very much for clarification. Yes, I did it wrong, and now the program does start, but the (4) above holds, right? Therefore I still think it's a bug in ld-linux.so, even though not an important one for me anymore. No, I don't think (4) holds. This is one of the most performance critical programs on a Linux system; it assumes that the input files are somewhat valid. not to mention that if you put any random .so because of LD_LIBRARY_PATH in the linker path and expect it to work properly whatever happens, then well, you're profoundly mistaken IMHO. That's exactly one of the reason why LD_LIBRARY_PATH (among other *PATH variables) is not kept across sudo's e.g.). And under unix you somehow trust other process sharing uids with you for not wanting to destroy the system. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpSmOrrrFYS2.pgp Description: PGP signature
Bug#435382: libc6: ld-linux.so segfault.
On Tue, Jul 31, 2007 at 10:20:29PM +0400, Sergei Organov wrote: Pierre Habouzit [EMAIL PROTECTED] writes: On Tue, Jul 31, 2007 at 11:57:23AM -0400, Daniel Jacobowitz wrote: On Tue, Jul 31, 2007 at 07:25:23PM +0400, Sergei Organov wrote: 4. Probably ld-linux.so itself should not segfault no matter what. Thank you very much for clarification. Yes, I did it wrong, and now the program does start, but the (4) above holds, right? Therefore I still think it's a bug in ld-linux.so, even though not an important one for me anymore. No, I don't think (4) holds. This is one of the most performance critical programs on a Linux system; it assumes that the input files are somewhat valid. not to mention that if you put any random .so because of LD_LIBRARY_PATH in the linker path and expect it to work properly whatever happens, then well, you're profoundly mistaken IMHO. Sorry, but I did not expect random crap called something.so to work properly, -- I just expected ld-linux.so *itself* not to segfault. Maybe I'm indeed mistaken believing that program segfault is *always* bug. Though if you guys insist ld-linux.so segfault is not a bug, I can cope with it, I think. you don't get it, given _random_ input, you can't expect _any_ program not to crash. E.g. the ld.so linker expect everything it uses as library to link them to be correct enough. If not, as it's very critical, it crashes. Remember, it's up to the administrator to know what he install in the linker paths, so he's supposed to have checked that a bit (or trust his distribution). You have added non standard paths in your LD_LIBRARY_PATH, it crashes. well, that's life. strlen(NULL) also crashes, and it's not the libc fault, it's because you pass invalid input data to strlen. That's exactly the same. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpAo6YRUUuoe.pgp Description: PGP signature
Bug#435021: libc6.1-dev: [alpha] unistd.h does not contain exit() prototype
On Sat, Jul 28, 2007 at 06:21:19PM +0300, Meelis Roos wrote:
Subject: libc6.1-dev: [alpha] unistd.h does not contain exit() prototype
Package: libc6.1-dev
Version: 2.6-4
Severity: normal
*** Please type your report below this line ***
[EMAIL PROTECTED]:~$ cat exittest.c
#include unistd.h
int main ()
{
exit(0);
}
[EMAIL PROTECTED]:~$ LANG=C gcc -o exittest exittest.c
exittest.c: In function 'main':
exittest.c:4: warning: incompatible implicit declaration of built-in function
'exit'
So it seems that unistd.h does not contain exit() prototype on alpha.
For a very good reason, it comes from stdlib.h and not unistd.h:
http://www.opengroup.org/onlinepubs/009695399/functions/exit.html
Cheers,
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpDwnhCF3fDT.pgp
Description: PGP signature
Bug#420604: nscd: coredumps (ldap related?)
On Thu, Jul 26, 2007 at 05:12:11PM -0400, Jameson Rollins wrote: I have been experiencing what I believe is this same problem on an etch amd64 machine. We started experiencing weird passwd resolution issues for LDAP users that I traced to a failing nscd server. When started manually with the -d option, the following failure occurs within the first 30 seconds: zajos:0:~# /usr/sbin/nscd -d 1508: add new entry Dherzka of type GETPWBYNAME for passwd to cache (first) nscd: cache.c:144: cache_add: Assertion `newp-key + newp-len = table-head-first_free' failed. Aborted zajos:134:~# the problem is fixed in etch2 package (or etch3 I don't remember clearly). -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgptpdXAmKkj9.pgp Description: PGP signature
Bug#420604: nscd: coredumps (ldap related?)
On Thu, Jul 26, 2007 at 11:21:21PM +0200, Pierre Habouzit wrote: On Thu, Jul 26, 2007 at 05:12:11PM -0400, Jameson Rollins wrote: I have been experiencing what I believe is this same problem on an etch amd64 machine. We started experiencing weird passwd resolution issues for LDAP users that I traced to a failing nscd server. When started manually with the -d option, the following failure occurs within the first 30 seconds: zajos:0:~# /usr/sbin/nscd -d 1508: add new entry Dherzka of type GETPWBYNAME for passwd to cache (first) nscd: cache.c:144: cache_add: Assertion `newp-key + newp-len = table-head-first_free' failed. Aborted zajos:134:~# the problem is fixed in etch2 package (or etch3 I don't remember clearly). Hmmm sorry, I was confused, it's another bug. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpfH9OCzTk9A.pgp Description: PGP signature
Bug#431243: nscd error/warning on no more memory for database 'hosts'
tag 431243 + wontfix thanks On Wed, Jul 25, 2007 at 01:28:23PM +0100, Ronny Adsetts wrote: Hi, I see this error too: nscd: 10645 no more memory for database 'hosts' Anything I can do to help debug and find a solution? The computer exhibiting the error was running fine with no errors doing ldap only. Once I'd moved our mail services on to it (exim4, spamassassin, clamav, dovecot, mysql, ldap), I started getting the log message. Server is not busy load wise - delivers about 7000 emails a day to a mixture of forwards and maildir mail boxes. nscd is a sucky cache daemon for hosts. We strongly recommend to disable the caching for hosts, and to use a proper DNS cache. I can recommend pdnsd that is very useful in that regard, and supports many more features than nscd does. In lenny, hosts caching is disabled in nscd. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgph9TKsnQ0zP.pgp Description: PGP signature
Bug#434294: closed by Pierre Habouzit [EMAIL PROTECTED] (Re: Bug#434294: libc6: buggy unlocking of an unlocked pthread_rwlock_t)
On Mon, Jul 23, 2007 at 11:05:09AM +0200, Tim Blechmann wrote: please learn how to use errno. When a call fails in posix it returns a negative value, usually -1, and sets errno. you must test errno for EPERM. not the return value. quoting man pthread_rwlock_unlock: If successful, the pthread_rwlock_unlock() function shall return zero; otherwise, an error number shall be returned to indicate the error. maybe this is a bit mistakable? anyway, pthread_rwlock_unlock returns 0, not -1 and not EPERM yeah, I was wrong, I read the manpage to quickly. Anyways, you got your answer on the glibc bugzilla already. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpH7aqPfU5Ro.pgp Description: PGP signature
Bug#433857: [FTBFS] Missing: ../../../src/libffi/src/m68k/ffi.c:13:26: error: asm/cachectl.h: No such file or directory
On Thu, Jul 19, 2007 at 10:47:59PM +0100, Hector Oron wrote: Package: linux-kernel-headers Version: 2.6.21-6 Hello, Missing asm/cachectl.h 1 #ifndef _M68K_CACHECTL_H 2 #define _M68K_CACHECTL_H 3 4 /// Definitions for the cacheflush system call. 5 6 #define FLUSH_SCOPE_LINE1 /// Flush a cache line 7 #define FLUSH_SCOPE_PAGE2 /// Flush a page 8 #define FLUSH_SCOPE_ALL 3 /// Flush the whole cache -- superuser only 9 00010 #define FLUSH_CACHE_DATA1 /// Writeback and flush data cache 00011 #define FLUSH_CACHE_INSN2 /// Flush instruction cache 00012 #define FLUSH_CACHE_BOTH3 /// Flush both caches 00013 00014 #endif // _M68K_CACHECTL_H FYI, lkh is deprecated, your package should use linux-libc-dev instead. So this bug will be ignored. Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpGl0tjkuew2.pgp Description: PGP signature
Bug#433962: libc6-dev: error including netinet/if_fddi.h
reassign 433962 net-tools
forcemerge 428952 433962
thanks
On Fri, Jul 20, 2007 at 12:23:51PM -0400, Daniel Schepler wrote:
Package: libc6-dev
Version: 2.6-2
Severity: important
Tags: sid
Blocks: 428952
On an i386 sid system (with linux-libc-dev version 2.6.22):
[EMAIL PROTECTED]:/tmp$ cat test.c
#include netinet/if_fddi.h
[EMAIL PROTECTED]:/tmp$ gcc -c test.c
In file included from /usr/include/netinet/if_fddi.h:26,
from test.c:1:
/usr/include/linux/if_fddi.h:88: error: expected specifier-qualifier-list
before ‘__be16’
This is causing net-tools to FTBFS (bug #428952).
--
Daniel Schepler
This is not a bug, it is because you have to #include linux/types.h
now that we used the headers officially exported by the linux tree, and
not linux-kernel-headers anymore.
As a general note, the problems with __[lb]e{8,16,32,64} are caused by
missing #include linux/types.h in the FTBFS-ing sources, and the
sources have to be fixed, as linux-kernel-headers was kind of a hack,
and linux-libc-dev is supposed to be an official thing now.
Cheers,
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpaj7fSiemYi.pgp
Description: PGP signature
Bug#433500: libc6-dev uninstallable
On Tue, Jul 17, 2007 at 05:21:22PM +0100, Claudio Saavedra wrote: On Tue, 2007-07-17 at 18:06 +0200, Pierre Habouzit wrote: On Tue, Jul 17, 2007 at 04:28:54PM +0100, Claudio Saavedra wrote: Package: libc6-dev Severity: grave Justification: renders package unusable After having upgraded Debian, libc6-dev got uninstalled. Now I can't install it. Apt reports the following: use apt-get dist-upgrade and not upgrade. FYI, that's what I did *before* reporting the bug. It doesn't really fix it and it is still uninstallable. linux-kernel-headers does not exists, you have to install linux-libc-dev now. Maybe sth is not resolved properly by your apt for one reason or the other, but the package is definitely installable on my machine. ┌─(18:44) └[artemis] dpkg -l libc6-dev linux-libc-dev Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersion Description +++-===-=-== ii libc6-dev 2.6-2 GNU C Library: Development Libraries and Header Files ii linux-libc-dev 2.6.22-1 Linux Kernel Headers for development libc6-dev 2.6-2 is built on all archs, and there is at least. so what can I say ... there is nothing to fix. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpapmEXyC3ho.pgp Description: PGP signature
Bug#433500: libc6-dev uninstallable
On Tue, Jul 17, 2007 at 06:04:17PM +0100, Claudio Saavedra wrote: On Tue, 2007-07-17 at 18:48 +0200, Pierre Habouzit wrote: linux-kernel-headers does not exists, you have to install linux-libc-dev now. Maybe sth is not resolved properly by your apt for one reason or the other, but the package is definitely installable on my machine. Installed linux-libc-dev which uninstalled linux-kernel-headers. However, libc6-dev is still not installable. Reason: no installation candidate. ┌─(19:25) └[artemis] apt-cache policy libc6-dev libc6-dev: Installed: 2.6-2 Candidate: 2.6-2 Version table: *** 2.6-2 0 500 ftp://mad sid/main Packages 500 ftp://mad lenny/main Packages 100 /var/lib/dpkg/status 2.3.6.ds1-13 0 500 ftp://mad etch/main Packages Again, it works here, I have a libc6-dev. I don't know what you did with your system, but the problem is definitely on _your_ end. You may have hold a package, or tweaked /etc/apt/preferences I don't know, but as you can see, there _is_ a libc6-dev and it's installed here. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp7qe2BsYGNB.pgp Description: PGP signature
Bug#433337: libc6-i386 conflicts with lib32z1
reassign 47 lib32z1 forcemerge 47 432326 kthxbye THIS IS NOT A LIBC BUG FOR GOD'S SAKE. On Tue, Jul 17, 2007 at 12:09:23AM +1200, Linas Jakucionis wrote: Package: libc6-i386 Version: 2.6-2 I am getting the following errors when upgrading Debian (amd64): jiffy:/home/bro1# apt-get install Reading package lists... Done Building dependency tree Reading state information... Done You might want to run `apt-get -f install' to correct these. The following packages have unmet dependencies: libc6-i386: Depends: libc6 (= 2.5-11) but 2.6-2 is installed E: Unmet dependencies. Try using -f. jiffy:/home/bro1# jiffy:/home/bro1# apt-get install -f Reading package lists... Done Building dependency tree Reading state information... Done Correcting dependencies... Done The following packages were automatically installed and are no longer required: libgcj7-0 libnautilus-burn3 libxklavier10 libgucharmap4 libmyspell3c2 libedataserver1.2-7 libecal1.2-6 libedata-cal1.2-5 guile-1.6-libs libcamel1.2-8 libgpod0 libmdbtools libguile-ltdl-1 libavcodec0d gaim-data libx264-54 libavahi-core4 libstlport5.1 libpoppler0c2-glib libedataserverui1.2-6 libcurl3 libegroupwise1.2-10 libexchange-storage1.2-1 libpostproc0d libservlet2.3-java gtkhtml3.8 libiw28 libavformat0d libsnmp9 mkisofs libebook1.2-5 Use 'apt-get autoremove' to remove them. The following extra packages will be installed: libc6-i386 The following packages will be upgraded: libc6-i386 1 upgraded, 0 newly installed, 0 to remove and 203 not upgraded. Need to get 0B/3706kB of archives. After unpacking 24.6kB of additional disk space will be used. Do you want to continue [Y/n]? y (Reading database ... 213795 files and directories currently installed.) Preparing to replace libc6-i386 2.5-11 (using /libc6-i386_2.6-2_amd64.deb) ... Unpacking replacement libc6-i386 ... dpkg: error processing /var/cache/apt/archives/libc6-i386_2.6-2_amd64.deb (--unpack): trying to overwrite `/usr/lib32', which is also in package lib32z1 Errors were encountered while processing: /var/cache/apt/archives/libc6-i386_2.6-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) Version info: Package: libc6-i386 Status: install ok installed Priority: optional Section: libs Installed-Size: 9000 Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org Architecture: amd64 Source: glibc Version: 2.5-11 Replaces: libc6-dev-i386 Depends: libc6 (= 2.5-11) Conflicts: ia32-libs (= 1.5) Description: GNU C Library: 32bit shared libraries for AMD64 This package includes shared versions of the standard C library and the standard math library, as well as many others. This is the 32bit version of the library, meant for AMD64 systems. Package: lib32z1 Status: install ok installed Priority: optional Section: libs Installed-Size: 156 Maintainer: Mark Brown [EMAIL PROTECTED] Architecture: amd64 Source: zlib Version: 1:1.2.3.3.dfsg-3 Replaces: ia32-libs ( 1.5) Depends: libc6-i386 (= 2.5-5) Description: compression library - 32 bit runtime zlib is a library implementing the deflate compression method found in gzip and PKZIP. This package includes a 32 bit version of the shared library. Package: libc6 Status: install ok installed Priority: required Section: libs Installed-Size: 11284 Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org Architecture: amd64 Source: glibc Version: 2.6-2 Provides: glibc-2.6-1 Depends: libgcc1 Suggests: locales, glibc-doc Conflicts: libterm-readline-gnu-perl ( 1.15-2), tzdata ( 2007e-2) Conffiles: /etc/init.d/glibc.sh 60f72cbc726109061ee449b3d9994271 /etc/gai.conf b0b535eb2d4a67d0eb698d9160691103 /etc/ld.so.conf.d/x86_64-linux-gnu.conf 593ad12389ab2b6f952e7ede67b8fbbf Description: GNU C Library: Shared libraries Contains the standard libraries that are used by nearly all programs on the system. This package includes shared versions of the standard C library and the standard math library, as well as many others. Please let me know if you need any other information. Thanks Linas -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpRV18ATP2lN.pgp Description: PGP signature
Re: Should libc6-dev conflict against binutils in experimental?
On Fri, Jul 13, 2007 at 01:01:31PM +0300, Touko Korpela wrote: On Fri, Jul 13, 2007 at 07:19:16AM +0200, Aurelien Jarno wrote: Current conflicts binutils ( 2.17cvs20070426-1) doesn't match version in experimental. Maybe it should be added too? That's really not possible, the version in experimental is higher (from the debian version point of view) than the version in unstable. If we do that, that will causes some problems later. Maybe adding another conflict entry for experimental versions or just for latest version in experimental? What is the point ? I mean, people using experimental should know what they are doing. We won't bloat the conflict line of our packages for them. binutils versioning is inconsistent between unstable and experimental and _that_ is the real issue, go talk to the binutils maintainer, he's more able to fix that IMHO. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp723R4vemXl.pgp Description: PGP signature
Bug#432757: Upgrade is impossible. Conflicts with lib32z1 package
reassign 432757 lib32z1 forcemerge 432757 432326 kthxbye -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpkWvhywk9Cw.pgp Description: PGP signature
Bug#432844: Unable to install libc6-i386 on debian unstable (amd64 arch.)
reassign 432844 lib32z1 forcemerge 432844 432326 kthxbye I feel tired ... On Thu, Jul 12, 2007 at 02:38:50PM +0200, BH wrote: Package: libc6-i386 Version: 2.6-2 The packages were broken yesterday, but I tried to wait one day ... sems nobody noticed, so I'm reporting this bug. Using debian unstable on amd64 apt-get update;apt-get upgrade followed by apt-get -f install end with this: Preparing to replace libc6-i386 2.5-11 (using /libc6-i386_2.6-2_amd64.deb) ... Unpacking replacement libc6-i386 ... dpkg: error processing /var/cache/apt/archives/libc6-i386_2.6-2_amd64.deb (--unpack): trying to overwrite `/usr/lib32', which is also in package lib32z1 Preparing to replace libc6 2.6-1 (using .../archives/libc6_2.6-2_amd64.deb) ... Unpacking replacement libc6 ... Errors were encountered while processing: /var/cache/apt/archives/libc6-i386_2.6-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) # dpkg -p lib32z1 |grep Ver Version: 1:1.2.3.3.dfsg-3 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpyDFCGD30Uv.pgp Description: PGP signature
Bug#431858: CVE-2007-3508: Integer overflow
On Thu, Jul 05, 2007 at 03:54:10PM +0200, Laurent Bonnaud wrote: Package: libc6 Version: 2.5-11 Severity: important Hi, here is the problem: http://www.gentoo.org/security/en/glsa/glsa-200707-04.xml FWIW this has been discussed with the security team already, there is no way to exploit this, whatever the gentoo GLSA says. It does not mean that we won't fix it, but it's not a big problem at all, I'm not even sure it deserves the important severity :) Cheers, -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgpoErytf76Sc.pgp Description: PGP signature
Bug#425905: nscd: should it depend on libc6-amd64
On Tue, Jun 19, 2007 at 01:48:24PM +1200, Andrew Ruthven wrote: Hi, The latest version of nscd (2.5-11) has the bogus dependency on libc6-amd65 again: Package: nscd Priority: optional Section: admin Installed-Size: 244 Maintainer: GNU Libc Maintainers debian-glibc@lists.debian.org Architecture: i386 Source: glibc Version: 2.5-11 Depends: libc6-amd64 (= 2.5-5) it is a dpkg-shlibdeps bug, and should be sorted out at some point. The problem is known, and consequences are quite harmless, as what should appear is libc6 (= 2.5-5) and it happens that libc6-amd64 also neds libc6 (= 2.5-5). So it will be sorted out eventually. -- ·O· Pierre Habouzit ··O[EMAIL PROTECTED] OOOhttp://www.madism.org pgp9EgKOflbBr.pgp Description: PGP signature
Bug#429256: linux-kernel-headers: Support SH4 target
:56:03.0 +0900
+@@ -26,7 +26,11 @@
+ return x;
+ }
+
++#if !defined(__STRICT_ANSI__)
+ static inline __u64 ___arch__swab64(__u64 val)
++#else
++static __inline__ __u64 ___arch__swab64(__u64 val)
++#endif
+ {
+ union {
+ struct { __u32 a,b; } s;
diff -urN a/debian/patches/series b/debian/patches/series
--- a/debian/patches/series 2007-06-16 02:26:17.0 +
+++ b/debian/patches/series 2007-06-16 01:55:11.0 +
@@ -40,3 +40,4 @@
m68k-asm-unistd.patch -p0
m68k-asm-user.patch -p0
alpha-asm-compiler.patch -p1
+asm-sh-byteorder-inline.patch -p0
diff -urN a/debian/rules b/debian/rules
--- a/debian/rules2007-06-16 02:26:17.0 +
+++ b/debian/rules2007-06-16 02:16:40.0 +
@@ -17,6 +17,7 @@
kernel_arch := $(patsubst hppa,parisc,$(kernel_arch))
kernel_arch := $(patsubst mipsel,mips,$(kernel_arch))
kernel_arch := $(patsubst amd64,x86_64,$(kernel_arch))
+kernel_arch := $(patsubst sh4,sh,$(kernel_arch))
other_headers := $(wildcard others/asm-$(kernel_arch)-*)
other_headers_inst := $(patsubst
others/asm-$(kernel_arch)-%,%,$(other_headers))
--
·O· Pierre Habouzit
··O[EMAIL PROTECTED]
OOOhttp://www.madism.org
pgpQhg6B3VSpw.pgp
Description: PGP signature
