[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug #64434] 1.29.0 testsuite failures on Debian
|
From: |
Yavor Doganov |
|
Subject: |
[bug #64434] 1.29.0 testsuite failures on Debian |
|
Date: |
Mon, 17 Jul 2023 10:59:03 -0400 (EDT) |
URL:
<https://savannah.gnu.org/bugs/?64434>
Summary: 1.29.0 testsuite failures on Debian
Group: GNUstep
Submitter: yavor
Submitted: Mon 17 Jul 2023 05:58:59 PM EEST
Category: Base/Foundation
Severity: 3 - Normal
Item Group: Bug
Status: None
Privacy: Public
Assigned to: None
Open/Closed: Open
Discussion Lock: Any
_______________________________________________________
Follow-up Comments:
-------------------------------------------------------
Date: Mon 17 Jul 2023 05:58:59 PM EEST By: Yavor Doganov <yavor>
I apologise that it took me so long to report this. On Debian unstable (GCC
13.1.0, GLIBC 2.37, ICU 72.1) 26 tests related to time zones fail:
base/NSCalendar/era.m:
Failed test: (2023-07-17 11:47:52.610 +0000) era.m:51...
getHour:minute:second:nanosecond:fromDate: returns correct hour
base/NSCalendarDate/test00.m:
Failed test: (2023-07-17 11:47:57.170 +0000) test00.m:113 ...
+dateWithString:calendarFormat:locale: handles Africa/Addis_Ababa
Failed test: (2023-07-17 11:47:57.171 +0000) test00.m:252 ... date check
with 2002-03-31 01:30:00
Failed test: (2023-07-17 11:47:57.171 +0000) test00.m:267 ... date check
with 2002-03-31 01:30:00
Failed test: (2023-07-17 11:47:57.171 +0000) test00.m:271 ... date check
with 2002-03-31 00:30:00
Failed test: (2023-07-17 11:47:57.172 +0000) test00.m:428 ... date year
calculation preserves timezone
base/NSCalendarDate/test02.m:
Failed test: (2023-07-17 11:47:57.678 +0000) test02.m:171 ... %Z format
works in description
Failed test: (2023-07-17 11:47:57.678 +0000) test02.m:175 ... %z format
works in description
Failed test: (2023-07-17 11:47:57.678 +0000) test02.m:195 ... %H%M format
works in description
base/NSDateFormatter/general.m:
Failed test: (2023-07-17 11:48:23.996 +0000) general.m:81 ... EST time
zone is correctly accounted for.
base/NSTimeZone/create.m:
Failed test: (2023-07-17 11:52:32.777 +0000) create.m:32 ...
+timeZoneWithAbbreviation works
Failed test: (2023-07-17 11:52:32.777 +0000) create.m:36 ...
+timeZoneWithName works
base/NSTimeZone/localtime.m:
Failed test: (2023-07-17 11:52:33.060 +0000) localtime.m:62 ...
+timeZoneWithName works
Failed test: (2023-07-17 11:52:33.060 +0000) localtime.m:67 ... pre-1996
standard time offset vs UTC found for System Europe/Paris
Failed test: (2023-07-17 11:52:33.060 +0000) localtime.m:71 ... pre-1996
DST time offset vs UTC found for System Europe/Paris
Failed test: (2023-07-17 11:52:33.060 +0000) localtime.m:76 ... post-1996
standard time offset vs UTC found for System Europe/Paris
Failed test: (2023-07-17 11:52:33.060 +0000) localtime.m:80 ... post-1996
DST time offset vs UTC found for System Europe/Paris
base/NSTimeZone/use.m:
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:60 ... can calculate
next DST transition
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:67 ... Correctly
localizes Europe/Brussels standard time zone name
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:71 ... Correctly
localizes Europe/Brussels DST time zone name
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:75 ... Correctly
localizes Europe/Brussels short time zone name
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:79 ... Correctly
localizes Europe/Brussels short DST time zone name
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:87 ... Correctly
localizes America/Sao_Paulo standard time zone name
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:91 ... Correctly
localizes America/Sao_Paulo DST time zone name
Failed test: (2023-07-17 11:52:33.395 +0000) use.m:110 ... Returns
correct Daylight Saving offset.
Failed test: (2023-07-17 11:52:33.396 +0000) use.m:113 ... Returns
correct Daylight Saving offset.
>From the test log:
Running base/NSCalendar/era.m...
Start set: era.m:31 ... NSCalendar getEra:year:month:day:fromDate and
getHour:minute:second:nanosecond:fromDate tests
Unable to create time zone for name: 'Etc/UTC'
(source '(null)').
You can override the timezone name by setting the 'Local Time Zone'
NSUserDefault via the 'defaults' command line utility, a Preferences
application, or some other utility.
eg "defaults write NSGlobalDomain 'Local Time Zone' 'Africa/Nairobi'"
See '(null)'
for the standard timezones such as 'GB-Eire' or 'America/Chicago'.
The problem is that Debian has /usr/share/zoneinfo/posix removed with the
reasoning that it's unnecessary legacy while current GNUstep code relies on
it. I suggest a simple fix as in the attached patch (TZDIR is defined in
tzdb.h).
With that patch applied, two test files abort:
base/NSCalendarDate/test00.m:
Failed file: test00.m aborted without running all tests!
base/NSTimeZone/create.m:
Failed file: create.m aborted without running all tests!
Log:
Running base/NSCalendarDate/test00.m...
...
Passed test: (2023-07-17 13:05:44.052 +0000) test00.m:81 ...
+dateWithString:calendarFormat:locale: objects to missing timezone
2023-07-17 13:05:44.176 test00[1015174:1015174] Unable to obtain time zone
`tzdata.zi'... <NSException: 0x55c7707e74a0> NAME:GSTimeZoneFileException
REASON:data too large INFO:(null)
2023-07-17 13:05:44.178 test00[1015174:1015174] Unable to obtain time zone
`leap-seconds.list'... <NSException: 0x55c77080d380>
NAME:GSTimeZoneFileException REASON:cannot load data INFO:(null)
2023-07-17 13:05:44.612 test00[1015174:1015174] Unable to obtain time zone
`leapseconds'... <NSException: 0x55c7710b9b20> NAME:GSTimeZoneFileException
REASON:cannot load data INFO:(null)
2023-07-17 13:05:44.953 test00[1015174:1015174] *** -[GSCInlineString hash]:
message sent to deallocated instance 0x55c771892da0
/usr/bin/gnustep-tests: line 396: 1015174 Aborted ( .
./TestInfo > /dev/null 2>&1; $RUN_CMD )
Failed file: test00.m aborted without running all tests!
Running base/NSTimeZone/create.m...
...
Passed test: (2023-07-17 13:10:18.047 +0000) create.m:28 ...
+timeZoneForSecondsFromGMT fails for bad offset
2023-07-17 13:10:18.055 create[1024695:1024695] Unable to obtain time zone
`tzdata.zi'... <NSException: 0x5593354bcb10> NAME:GSTimeZoneFileException
REASON:data too large INFO:(null)
2023-07-17 13:10:18.055 create[1024695:1024695] Unable to obtain time zone
`leap-seconds.list'... <NSException: 0x5593354e22c0>
NAME:GSTimeZoneFileException REASON:cannot load data INFO:(null)
2023-07-17 13:10:18.156 create[1024695:1024695] Unable to obtain time zone
`leapseconds'... <NSException: 0x559335d8eb40> NAME:GSTimeZoneFileException
REASON:cannot load data INFO:(null)
2023-07-17 13:10:18.255 create[1024695:1024695] *** -[GSCInlineString hash]:
message sent to deallocated instance 0x559336567cd0
/usr/bin/gnustep-tests: line 396: 1024695 Aborted ( .
./TestInfo > /dev/null 2>&1; $RUN_CMD )
Failed file: create.m aborted without running all tests!
Here's a backtrace:
Program received signal SIGABRT, Aborted.
__pthread_kill_implementation (threadid=<optimized out>, signo=signo@entry=6,
no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
44 ./nptl/pthread_kill.c: Няма такъв файл или
директория.
(gdb) bt
#0 __pthread_kill_implementation (threadid=<optimized out>,
signo=signo@entry=6, no_tid=no_tid@entry=0) at ./nptl/pthread_kill.c:44
#1 0x00007ffff76a815f in __pthread_kill_internal (signo=6,
threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2 0x00007ffff765a472 in __GI_raise (sig=sig@entry=6)
at ../sysdeps/posix/raise.c:26
#3 0x00007ffff76444b2 in __GI_abort () at ./stdlib/abort.c:79
#4 0x00007ffff79b2b65 in GSLogZombie (
sel=0x7ffff7d648a0 <_OBJC_SELECTOR_TABLE+64>, o=0x5555557e4ba0)
at ./Source/NSObject.m:184
#5 -[NSZombie forwardInvocation:] (self=0x5555557e4ba0, _cmd=<optimized out>,
anInvocation=0x55555563f860) at ./Source/NSObject.m:2523
#6 0x00007ffff7ba9d05 in GSFFIInvocationCallback (cif=0x5555557fe5f0,
retp=0x7fffffffda80, args=<optimized out>, user=0x5555557fe5b0)
at ./Source/GSFFIInvocation.m:614
#7 0x00007ffff7ef6d95 in ffi_closure_unix64_inner (cif=<optimized out>,
fun=<optimized out>, user_data=0x5555557fe5b0, rvalue=<optimized out>,
reg_args=<optimized out>, argp=0x7fffffffdab0 "\360\300\177UUU")
at ../src/x86/ffi64.c:899
#8 0x00007ffff7ef7110 in ffi_closure_unix64 () at ../src/x86/unix64.S:303
#9 0x00007ffff79c250d in GSIMapAddPair (map=map@entry=0x5555557d4238,
key=key@entry=..., value=..., value@entry=...)
at ../Headers/GNUstepBase/GSIMap.h:1077
#10 0x00007ffff79c281f in -[GSMutableDictionary setObject:forKey:] (
self=self@entry=0x5555557d4230,
_cmd=_cmd@entry=0x7ffff7e38bd0 <_OBJC_SELECTOR_TABLE+688>,
anObject=anObject@entry=0x5555557e4030, aKey=0x5555557e4ba0)
at ./Source/GSDictionary.m:460
#11 0x00007ffff7b50218 in +[NSTimeZone abbreviationDictionary] (
self=<optimized out>, _cmd=<optimized out>) at ./Source/NSTimeZone.m:1030
#12 0x00007ffff7b4ed5e in +[NSTimeZone timeZoneWithAbbreviation:] (
self=0x7ffff7e39d40 <_OBJC_Class_NSTimeZone>, _cmd=<optimized out>,
abbreviation=0x555555567840 <_OBJC_INSTANCE_9.1>)
at ./Source/NSTimeZone.m:1986
#13 0x0000555555562db8 in main () at create.m:31
These fail only when gnustep-base is not installed (like in a chroot); on a
machine with an installed library you can simulate the situation by moving
away or renaming abbreviations.plist. I spent some time analyzing this (how
much I'm ashamed to say) and came to the conclusion that abbrev in
GSTimeZoneDetail-initWithTimeZone:withAbbrev:withOffset:withDST: is not
retained. The comment there says that it's being retained in aZone but
apparently that is no longer true. The proposed second patch fixes this,
along with the (cosmetic) change to skip loading of files that are known not
to be zone files, in addition to .tab.
These tests fail on all 32bit architectures:
base/NSTimeZone/localtime.m:
Failed test: (2023-01-04 08:24:24.331 +0000) localtime.m:47 ... post-2038
standard time offset vs UTC found for user-supplied Europe/Paris TZDB v2
Failed test: (2023-01-04 08:24:24.332 +0000) localtime.m:47 ... post-2038
standard time offset vs UTC found for user-supplied buggy Europe/Paris TZDB v2
without v2 header
These are doomed to fail so a straightforward fix is proposed in the third
patch.
These tests fail on hppa and powerpc (32bit):
base/NSCalendarDate/test00.m:
Failed test: (2023-01-12 21:19:49.495 +0100) test00.m:254 ... date check
with 2002-03-31 01:30:00
Failed test: (2023-01-12 21:19:49.496 +0100) test00.m:269 ... date check
with 2002-03-31 01:30:00
Failed test: (2023-01-12 21:19:49.496 +0100) test00.m:273 ... date check
with 2002-03-31 00:30:00
base/NSTimeZone/localtime.m:
Failed test: (2023-02-23 07:02:02.093 +0000) localtime.m:73 ... pre-1996
DST time offset vs UTC found for System Europe/Paris
Failed test: (2023-02-23 07:02:02.093 +0000) localtime.m:82 ... post-1996
DST time offset vs UTC found for System Europe/Paris
Failed test: (2023-02-23 07:02:02.093 +0000) localtime.m:29 ... pre-1996
DST time offset vs UTC found for user-supplied Europe/Paris TZDB v1
Failed test: (2023-02-23 07:02:02.093 +0000) localtime.m:40 ... post-1996
DST time offset vs UTC found for user-supplied Europe/Paris TZDB v1
Failed test: (2023-02-23 07:02:02.093 +0000) localtime.m:29 ... pre-1996
DST time offset vs UTC found for user-supplied Europe/Paris TZDB v2
Failed test: (2023-02-23 07:02:02.093 +0000) localtime.m:40 ... post-1996
DST time offset vs UTC found for user-supplied Europe/Paris TZDB v2
Failed test: (2023-02-23 07:02:02.093 +0000) localtime.m:29 ... pre-1996
DST time offset vs UTC found for user-supplied buggy Europe/Paris TZDB v1
without magic
Failed test: (2023-02-23 07:02:02.103 +0000) localtime.m:40 ... post-1996
DST time offset vs UTC found for user-supplied buggy Europe/Paris TZDB v1
without magic
Failed test: (2023-02-23 07:02:02.103 +0000) localtime.m:29 ... pre-1996
DST time offset vs UTC found for user-supplied buggy Europe/Paris TZDB v2
without v2 header
Failed test: (2023-02-23 07:02:02.103 +0000) localtime.m:40 ... post-1996
DST time offset vs UTC found for user-supplied buggy Europe/Paris TZDB v2
without v2 header
I don't have access to these systems (all my ppc machines are down) so I can't
provide more information for the time being.
Finally, these tests succeed in a C locale but they fail in my locale
bg_BG.UTF-8 (I haven't tried other locales but I assume it would fail there as
well):
base/NSCalendar/era.m:
Failed test: (2023-07-17 17:12:50.684 +0300) era.m:43 ...
getEra:year:month:day:fromDate: returns correct year
Failed test: (2023-07-17 17:12:50.684 +0300) era.m:44 ...
getEra:year:month:day:fromDate: returns correct month
Failed test: (2023-07-17 17:12:50.684 +0300) era.m:45 ...
getEra:year:month:day:fromDate: returns correct day
Failed test: (2023-07-17 17:12:50.684 +0300) era.m:51 ...
getHour:minute:second:nanosecond:fromDate: returns correct hour
Failed test: (2023-07-17 17:12:50.684 +0300) era.m:52 ...
getHour:minute:second:nanosecond:fromDate: returns correct minute
Failed test: (2023-07-17 17:12:50.684 +0300) era.m:53 ...
getHour:minute:second:nanosecond:fromDate: returns correct second
The values appear to be garbage and they're different every run:
(gdb) p year
$23 = 55511
(gdb) p month
$24 = 6
(gdb) p day
$25 = 15
This could be an ICU bug... or not.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Mon 17 Jul 2023 05:58:59 PM EEST Name:
0001-Move-include-tzdb.h-a-bit-earlier.patch Size: 1KiB By: yavor
Proposed patches fixing some of the reported issues
<http://savannah.gnu.org/bugs/download.php?file_id=54933>
-------------------------------------------------------
Date: Mon 17 Jul 2023 05:58:59 PM EEST Name:
0002-Retain-release-abbrev-in-GSTimeZoneDetail.patch Size: 2KiB By: yavor
Proposed patches fixing some of the reported issues
<http://savannah.gnu.org/bugs/download.php?file_id=54934>
-------------------------------------------------------
Date: Mon 17 Jul 2023 05:58:59 PM EEST Name:
0003-Skip-NSTimeZone-tests-relying-on-64bit-time_t-on-all.patch Size: 2KiB
By: yavor
Proposed patches fixing some of the reported issues
<http://savannah.gnu.org/bugs/download.php?file_id=54935>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?64434>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- [bug #64434] 1.29.0 testsuite failures on Debian,
Yavor Doganov <=