*** Please type your report below this line *** After glibc update, zdump -v segfault alpha300:~# zdump -v /etc/localtime Erreur de segmentation As a notice, zdump --version does not work (same on x86) Before the update, there was a different failure alpha300:~# zdump --version @(#)zdump.c 7.64 alpha300:~# zdump -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL Then you had to stop the program with ctrl/C After compilation of zdump from tzcode2007b.tar.gz with make zdump it show alpha300:~# ./zdump --version @(#)zdump.c 8.3 alpha300:~# ./zdump -v /etc/localtime /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL alpha300:~# so the behavior is same as before the update and it does not work as intented alpha300:~# 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 cpus detected : 1 this is my first report on debian, I find nothing for libc-2.3.2 I know #266438 for libc-2.2.5-11.2 and #266438 for libc-2.3.6.ds1
block 412569 by 412070 thanks Nope, it's just quite long. At least it takes a lot of time on my very recent and fast CPU, I expect it to last more on alphas that are quite older.
zdump works fine with libc6 version 2.3.2.ds1-22sarge4 but
segfaults with version 2.3.2.ds1-22sarge5.
biocyc07:~# zdump -v /etc/localtime
Segmentation fault
biocyc06:/etc# zdump -v /etc/localtime | grep 2007
/etc/localtime Sun Mar 11 09:59:59 2007 UTC = Sun Mar 11 01:59:59 2007 PST isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 11 10:00:00 2007 UTC = Sun Mar 11 03:00:00 2007 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 4 08:59:59 2007 UTC = Sun Nov 4 01:59:59 2007 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 4 09:00:00 2007 UTC = Sun Nov 4 01:00:00 2007 PST isdst=0 gmtoff=-28800
Timezone data is identical on both machines.
biocyc07:~# md5sum /usr/share/zoneinfo/US/Pacific
ad7be76a1d7216104d9004a73e200efc /usr/share/zoneinfo/US/Pacific
biocyc06:/etc# md5sum /usr/share/zoneinfo/US/Pacific
ad7be76a1d7216104d9004a73e200efc /usr/share/zoneinfo/US/Pacific
biocyc07:~# strace zdump -v /etc/localtime
execve("/usr/bin/zdump", ["zdump", "-v", "/etc/localtime"], [/* 17 vars */]) = 0
uname({sys="Linux", node="biocyc07", ...}) = 0
brk(0) = 0x503000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a9556a000
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
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=34110, ...}) = 0
mmap(NULL, 34110, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2a9556b000
close(3) = 0
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY) = 3
read(3, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\340\324"..., 640) = 640
fstat(3, {st_mode=S_IFREG|0755, st_size=1295328, ...}) = 0
mmap(NULL, 2354760, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x2a9566c000
mprotect(0x2a9578e000, 1166920, PROT_NONE) = 0
mmap(0x2a9586c000, 241664, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x100000) = 0x2a9586c000
mmap(0x2a958a7000, 15944, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x2a958a7000
close(3) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a958ab000
arch_prctl(0x1002, 0x2a958ab640) = 0
munmap(0x2a9556b000, 34110) = 0
open("/usr/lib/locale/locale-archive", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=290576, ...}) = 0
mmap(NULL, 290576, PROT_READ, MAP_PRIVATE, 3, 0) = 0x2a9556b000
close(3) = 0
brk(0) = 0x503000
brk(0x524000) = 0x524000
brk(0) = 0x524000
fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 3), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a955b2000
open("/etc/localtime", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=1017, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2a955b3000
read(3, "TZif\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\4\0\0\0\4\0"..., 4096) = 1017
close(3) = 0
munmap(0x2a955b3000, 4096) = 0
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
So on amd64, with 2.3.2.ds1-22sarge4 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL intrepid:~$ zdump --version @(#)zdump.c 7.64 Upgrading to 2.3.2.ds1-22sarge5 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC Segmentation fault intrepid:~$ zdump --version zdump: invalid option -- - zdump: usage is zdump [ -v ] [ -c cutoff ] zonename ... I think it broke on 64 bit arches. With 2.3.6.ds1-13 (unstable) I still get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL intrepid:~$ zdump --version @(#)zdump.c 7.66 On i386 I get: intrepid:~$ zdump -v /usr/share/zoneinfo/UTC /etc/localtime Fri Dec 13 20:45:52 1901 UTC = Fri Dec 13 20:45:52 1901 UTC isdst=0 gmtoff=0 /etc/localtime Sat Dec 14 20:45:52 1901 UTC = Sat Dec 14 20:45:52 1901 UTC isdst=0 gmtoff=0 /etc/localtime Mon Jan 18 03:14:07 2038 UTC = Mon Jan 18 03:14:07 2038 UTC isdst=0 gmtoff=0 /etc/localtime Tue Jan 19 03:14:07 2038 UTC = Tue Jan 19 03:14:07 2038 UTC isdst=0 gmtoff=0 On amd64, it never seems to show 1901 / 2038 properly. If I use a different timezone, and not using 2.3.2.ds1-22sarge5 the first 2 and last lines still look the same, but the rest between them look normal. Kurt
I noticed there was a lack on an available Alpha system that was blocking the fixing of 412569, and probably other, Debian/Alpha bugs. Any updates on this situation? With the upcoming DST change in the US coming on 4-NOV-2007, it would be nice to have zdump -v working on the Alpha platform. Thanks, Dave Gudewicz Abbott Labs
Hello all. This message is about bug #412569, but informations are also relevant to issue #200641. I looked deeper into zdump and gmtime issues. And I think there is no error in libc's gmtime or zdump. $ zdump -v /usr/share/zoneinfo/UTC /etc/localtime -9223372036854775808 = NULL /etc/localtime -9223372036854689408 = NULL /etc/localtime 9223372036854689407 = NULL /etc/localtime 9223372036854775807 = NULL $ In my opinion it is actually correct output. Documentation of zdump needs to be updated to fully reflect this strange (but correct) behaviour. Why?