glibc 2.3.5/ppc64 - lkh or llh
glibc 2.3.5 for ppc64 fails to build with our current version of linux-kernel-headers. Two solutions: - Update linux-kernel-headers to 2.6.11 and fix the patches to make them usable in userspace. - Use linux-libc-headers (from PLD) and push our changes upstream. I think the second is more apropriate for our needs. Bastian -- What terrible way to die. There are no good ways. -- Sulu and Kirk, That Which Survives, stardate unknown signature.asc Description: Digital signature
Strange non dying of gzip on amd64
Hi, while working with apt-ftparchive on amd64 it repeadatly deadlocks. After some debugging here is what I found happens: apt-ftparchive calls gzip with stdout to a pipe apt-ftparchive reads some data from the pipe till it has enough apt-ftparchive sends SIGINT apt-ftparchive reads blocking from the pipe to flush it and now everything hangs with gzip not dying. At that point the FDs of both programs are as follows: /proc/31752/fd: (apt-ftparchive) total 9 lrwx-- 1 katie debadmin 64 May 1 17:10 0 - /dev/pts/7 lrwx-- 1 katie debadmin 64 May 1 17:10 1 - /dev/pts/7 lrwx-- 1 katie debadmin 64 May 1 17:06 2 - /dev/pts/7 l-wx-- 1 katie debadmin 64 May 1 17:10 3 - /dev/null lrwx-- 1 katie debadmin 64 May 1 17:10 4 - /org/amd64.debian.net/database/packages-amd64.db lr-x-- 1 katie debadmin 64 May 1 17:10 5 - /org/amd64.debian.net/database/dists/unstable_main_binary-amd64.list lr-x-- 1 katie debadmin 64 May 1 17:10 6 - /org/amd64.debian.net/ftp/debian/pool/main/a/abc2ps/abc2ps_1.3.3-3_amd64.deb lr-x-- 1 katie debadmin 64 May 1 17:10 8 - pipe:[1792790] /proc/31793/fd: (gzip) total 3 lr-x-- 1 katie debadmin 64 May 1 17:10 0 - /org/amd64.debian.net/ftp/debian/pool/main/a/abc2ps/abc2ps_1.3.3-3_amd64.deb l-wx-- 1 katie debadmin 64 May 1 17:10 1 - pipe:[1792790] lrwx-- 1 katie debadmin 64 May 1 17:06 2 - /dev/null And gzip has the following backtrace: (gdb) bt #0 0x2af442fd in __lll_mutex_lock_wait () from /lib/libc.so.6 #1 0x2b0a2550 in _IO_stdfile_1_lock () from /lib/libc.so.6 #2 0x0421 in ?? () #3 0x2aedc9c6 in save_for_backup () from /lib/libc.so.6 #4 0x00070008 in ?? () #5 0x00080008 in ?? () #6 0x00080008 in ?? () #7 0x00080008 in ?? () #8 0x00080008 in ?? () #9 0x2aab30fa in do_lookup_versioned () from /lib64/ld-linux-x86-64.so.2 #10 0x2aedbfce in _IO_flush_all_internal () from /lib/libc.so.6 #11 0x2aedc1fb in _IO_cleanup () from /lib/libc.so.6 #12 0x2ae98d97 in exit () from /lib/libc.so.6 #13 0x00404fe4 in do_exit (exitcode=1) at gzip.c:1833 #14 signal handler called #15 0x2aedbe81 in _IO_flush_all_lockp () from /lib/libc.so.6 #16 0x2aedbfce in _IO_flush_all_internal () from /lib/libc.so.6 #17 0x2aedc1fb in _IO_cleanup () from /lib/libc.so.6 #18 0x2ae98d97 in exit () from /lib/libc.so.6 #19 0x00404fe4 in do_exit (exitcode=0) at gzip.c:1833 #20 0x00402b6a in main (argc=2, argv=0x7c88) at gzip.c:640 (gdb) The exact same happens if apt-ftparchive closes the pipe first, then sends SIGINT and then calls waitpid. gzip never dies. [sidenote: kill -9 on gzip makes it continue] So we are know wondering if this could be a glibc problem or a kernel problem. Kernel is a 2.6.11.6 with vserver (apt-ftparchive inside vserver) and libc6 is 2.3.2.ds1-21. $ cat /proc/version Linux version 2.6.11.6-vs195-farm1.0 ([EMAIL PROTECTED]) (gcc-Version 3.3.5 (Debian 1:3.3.5-12)) #1 SMP Sat Apr 2 12:53:04 CEST 2005 Any help is welcome. MfG Goswin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#271428: mapping unknown timezones
At Sat, 16 Apr 2005 16:39:08 +0200, Martin Dickopp wrote: martin f krafft [EMAIL PROTECTED] writes: also sprach Martin Dickopp [EMAIL PROTECTED] [2005.04.16.1552 +0200]: Therefore, any actual behavior (including the existing one as well as the suggested alternatives) would be standard conforming. I don't think I was criticising standards compliance... I didn't mean to say you did. But after reading the postings to the bug report (well, to be honest, after skimming them quickly... :) ), it seemed that nobody had yet looked up if the relevant standards do in fact mandate any specific behavior for the case of an invalid TZ, so I did that first. Apologies if I have missed something. I agreed to Dickopp (you read the standard in detail). This is the implementation dependent behavior. At Sat, 16 Apr 2005 14:57:15 +0200, martin f krafft wrote: If libc does not know the timezone you request, it should *not* fall back to GMT and claim that it is rendering the requested timezone. Read tzset() and think again. POSIX defined tzset() that affects timezone related functions does not return any error value. If you ask me, it should do either of the following, in decreasing order of my preference: cirrus:~ TZ=GOTO date W: unknown timezone: GOTO. Using UTC instead. Sat Apr 16 12:48:31 UTC 2005 cirrus:~ TZ=GOTO date Sat Apr 16 12:48:31 UTC 2005 cirrus:~ TZ=GOTO date E: unknown timezone: GOTO. Now, whether this is a strftime problem, or how to incorporate the above into strftime is not my concern. I am a user and not willing to figure out the libc dungeons. I just note that the current behaviour of date is misleading, and that is what this bug is all about. You became aware that you implicated two different concept - libc functions vs date command utilities. As I wrote repeatedly, it's hard to distinguish the timezone correctness with the current standard libc functions. If your wish is just for date command, and you did not request to change the current libc standard behavior, we can propose other fixes. The simplest idea is to use strptime and parse them, and check the validity. Another idea is to create new function tzvalid() that inspects the validity of timezone value. Other idea is date command parses /usr/share/timezone directory - it's a bit ugly change, though. Regards, -- gotom -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
