bugGNUstep - Bugs: bug #64434, 1.29.0 testsuite failures on Debian

Group
 
 

bug #64434: 1.29.0 testsuite failures on Debian

Submitter:  Yavor Doganov <yavor>
Submitted:  Mon 17 Jul 2023 02:58:59 PM UTC
   
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  None
Privacy:  Public Assigned to:  None
Open/Closed:  Open
* Mandatory Fields

Add a New Comment Rich Markup
   

Mon 17 Jul 2023 02:58:59 PM UTC, original submission:  

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.

Yavor Doganov <yavor>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #54933:  0001-Move-include-tzdb.h-a-bit-earlier.patch added by yavor (1KiB - text/x-patch - Proposed patches fixing some of the reported issues)
file #54934:  0002-Retain-release-abbrev-in-GSTimeZoneDetail.patch added by yavor (2KiB - text/x-patch - Proposed patches fixing some of the reported issues)
file #54935:  0003-Skip-NSTimeZone-tests-relying-on-64bit-time_t-on-all.patch added by yavor (2KiB - text/x-patch - Proposed patches fixing some of the reported issues)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by yavor (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-07-17 yavor Attached File- Added 0001-Move-include-tzdb.h-a-bit-earlier.patch, #54933
        Attached File- Added 0002-Retain-release-abbrev-in-GSTimeZoneDetail.patch, #54934
        Attached File- Added 0003-Skip-NSTimeZone-tests-relying-on-64bit-time_t-on-all.patch, #54935

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code