zdump -v does not correctly work on alpha. cat /proc/cpuinfo cpu : Alpha cpu model : EV45 cpu variation : 7 cpu revision : 0 cpu serial number : system type : Avanti system variation : 0 system revision : 0 system serial number : AY cycle frequency [Hz] : 267895671 est. timer frequency [Hz] : 1024.00 page size [bytes] : 8192 phys. address bits : 34 max. addr. space # : 63 BogoMIPS : 529.40 kernel unaligned acc : 0 (pc=0,va=0) user unaligned acc : 0 (pc=0,va=0) platform string : AlphaServer 300 4/266 Tested with zdump 7.64 and the last available version 8.3 on tzcode2007b.tar.gz My report is #412569 against libc-2.3.2.ds1-22sarge5 and gcc-3.3.5-13 on debian BTS After compilation of zdump from tzcode2007b.tar.gz with make zdump alpha300:~# ./zdump --version @(#)zdump.c 8.3 alpha300:~# ./zdump -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL As it fail too with this last zdump available, I would think I need to report it there too. I find other report related to 64bits arch on debian BTS #266438: zdump -v causes core dump on IA64 Linux Package: libc6.1 (2.2.5-11.2; fixed: glibc 2.3.5-3); #402776: zdump -v errors on 64 bit architectures Package: libc6.1 (glibc 2.3.6.ds1-8, 2.3.6.ds1-10); Gilles
On Mon, Feb 26, 2007 at 11:05:44PM +0100, Gilles Espinasse wrote:
Subject: zdump -v segfault on alpha
zdump -v does not correctly work on alpha. [...] After compilation of zdump from tzcode2007b.tar.gz with make zdump
Can you provide a stack backtrace? $ make CFLAGS=-g zdump $ gdb zdump r {whatever params needed to duplicate the segfault} bt Thanks, --Ken Pizzini
----- Original Message ----- From: "Ken Pizzini" <tz.@explicate.org> To: <tz@elsie.nci.nih.gov> Cc: "Gilles Espinasse" <g.esp@free.fr> Sent: Monday, February 26, 2007 11:15 PM Subject: Re: zdump -v segfault on alpha
On Mon, Feb 26, 2007 at 11:05:44PM +0100, Gilles Espinasse wrote:
Subject: zdump -v segfault on alpha
zdump -v does not correctly work on alpha. [...] After compilation of zdump from tzcode2007b.tar.gz with make zdump
Can you provide a stack backtrace? $ make CFLAGS=-g zdump $ gdb zdump r {whatever params needed to duplicate the segfault} bt
Thanks, --Ken Pizzini
I admit I have not been so clear zdump 8.3 does not segfault, only the last version (with no version number) provided on stable glibc debian. I am on the learning curb on debian, so I will compile only in a few days zdump provided by debian with debug flag I use strace against debian version execve("/usr/bin/zdump", ["zdump", "-v", "/etc/localtime"], [/* 17 vars */]) = 0 uname({sys="Linux", node="alpha300", ...}) = 0 brk(0) = 0x120012d78 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x20000018000 open("/etc/ld.so.preload", O_RDONLY) = -1 ENOENT (No such file or directory) open("/etc/ld.so.cache", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=9782, ...}) = 0 mmap(NULL, 9782, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2000001a000 close(3) = 0 access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory) open("/lib/libc.so.6.1", O_RDONLY) = 3 read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0&\220\1\0\0\0@\217\2"..., 640) = 640 fstat(3, {st_mode=S_IFREG|0755, st_size=1586880, ...}) = 0 mmap(NULL, 1660312, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2000002a000 mprotect(0x20000190000, 193944, PROT_NONE) = 0 mmap(0x2000019a000, 139264, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0x160000) = 0x2000019a000 mmap(0x200001bc000, 13720, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x200001bc000 close(3) = 0 munmap(0x2000001a000, 9782) = 0 open("/usr/lib/locale/locale-archive", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=321088, ...}) = 0 mmap(NULL, 321088, PROT_READ, MAP_PRIVATE, 3, 0) = 0x200001c0000 close(3) = 0 brk(0) = 0x120012d78 brk(0x120034d78) = 0x120034d78 brk(0) = 0x120034d78 brk(0x120036000) = 0x120036000 gettimeofday({1172644720, 119554}, NULL) = 0 fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000001a000 open("/etc/localtime", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0644, st_size=1082, ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000001c000 read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0"..., 8192) = 1082 close(3) = 0 munmap(0x2000001c000, 8192) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- +++ killed by SIGSEGV +++ Concerning zdump 8.3, I should say I did not wait enough time to see the full output That's because after the first two lines, nothing is printed during half a minute. Then depending of the timezone setting, more is displayed That's to show the time taken and a short output ls -l /etc/localtime lrwxrwxrwx 1 root root 33 Feb 28 06:03 /etc/localtime -> /usr/share/zoneinfo/posix/Factory time zdump -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL real 0m36.320s user 0m36.302s sys 0m0.012s that's to show a bigger output with a different timezone ls -l /etc/localtime lrwxrwxrwx 1 root root 38 Feb 28 07:21 /etc/localtime -> /usr/share/zoneinfo/posix/Europe/Paris zdump -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime Fri Mar 10 23:51:38 1911 UTC = Sat Mar 11 00:00:59 1911 PMT isdst=0 /etc/localtime Fri Mar 10 23:51:39 1911 UTC = Fri Mar 10 23:51:39 1911 WET isdst=0 ... (I cut here all the normal output) /etc/localtime Sun Mar 29 00:59:59 2037 UTC = Sun Mar 29 01:59:59 2037 CET isdst=0 /etc/localtime Sun Mar 29 01:00:00 2037 UTC = Sun Mar 29 03:00:00 2037 CEST isdst=1 /etc/localtime Sun Oct 25 00:59:59 2037 UTC = Sun Oct 25 02:59:59 2037 CEST isdst=1 /etc/localtime Sun Oct 25 01:00:00 2037 UTC = Sun Oct 25 02:00:00 2037 CET isdst=0 /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL So the problem is always at the beginning and the end of the loop. With zdump 8.3 strace show (I cut the beginning) gettimeofday({1172645543, 221676}, NULL) = 0 brk(0) = 0x120025ff8 brk(0x120047ff8) = 0x120047ff8 brk(0) = 0x120047ff8 brk(0x120048000) = 0x120048000 fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0 mmap(NULL, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2000001a000 open("/usr/local/etc/zoneinfo/GMT", O_RDONLY) = 3 read(3, "TZif2\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\1\0\0"..., 41448) = 118 close(3) = 0 open("/usr/local/etc/zoneinfo/posixrules", O_RDONLY) = -1 ENOENT (No such file or directory) access("/etc/localtime", R_OK) = 0 open("/etc/localtime", O_RDONLY) = 3 read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0"..., 41448) = 1082 close(3) = 0 write(1, "/etc/localtime -922337203685477"..., 44) = 44 write(1, "/etc/localtime -922337203685468"..., 44) = 44 write(1, "/etc/localtime Fri Mar 10 23:51"..., 84) = 84 write(1, "/etc/localtime Fri Mar 10 23:51"..., 84) = 84 ... (I cut here the standard lines) write(1, "/etc/localtime Sun Oct 25 00:59"..., 85) = 85 write(1, "/etc/localtime Sun Oct 25 01:00"..., 84) = 84 write(1, "/etc/localtime 9223372036854689"..., 43) = 43 write(1, "/etc/localtime 9223372036854775"..., 43) = 43 munmap(0x2000001a000, 8192) = 0 exit_group(0) = ? Gilles
On Wed, Feb 28, 2007 at 08:03:33AM +0100, Gilles Espinasse wrote:
I use strace against debian version [snip] read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\f\0\0\0\f\0"..., 8192) = 1082
Because that is TZif\0 instead of TZif2, I strongly suspect that the version of tzcode used by this release of Debian was before proper support for 64-bit time_t values was added. What is the output of this command (fix the path if Debian installed zdump somewhere else): strings /usr/sbin/zdump | grep '@(#)'
Concerning zdump 8.3, I should say I did not wait enough time to see the full output That's because after the first two lines, nothing is printed during half a minute. Then depending of the timezone setting, more is displayed
Yeah, that's becaue zdump.c:delta() actually steps through time year-by-year from the minimum to the maximum representable years. This is a simple and reliable method, and with a 32-bit time_t it is fast enough to not be worth using a less-obviously-correct algorithm, but for a 64-bit time_t it does seem a bit silly. On the other hand, getting it _right_, avoiding calculation overflows and allowing for all the different types that time_t might have is a bit of chore, and since zdump -v is run infrequently it hasn't yet been worth the effort to fix this. --Ken Pizzini
participants (2)
-
Gilles Espinasse -
Ken Pizzini