Обсуждение: pltcl tests fail with FreeBSD 13.2
Hi, I saw that CI image builds for freebsd were failing, because 13.1, used until now, is EOL. Update to 13.2, no problem, I thought. Ran a CI run against 13.2 - unfortunately that failed. In pltcl of all places. https://api.cirrus-ci.com/v1/artifact/task/5275616266682368/testrun/build/testrun/pltcl/regress/regression.diffs Notably both 13.1 and 13.2 are using tcl 8.6.13. The code for the relevant function is this: create function tcl_date_week(int4,int4,int4) returns text as $$ return [clock format [clock scan "$2/$3/$1"] -format "%U"] $$ language pltcl immutable; select tcl_date_week(2010,1,26); It doesn't surprise me that there are problems with above clock scan, it uses the MM/DD/YYYY format without making that explicit. But why that doesn't work on freebsd 13.2, I can't explain. It looks like tcl specifies the MM/DD/YYYY bit for "free format scans": https://www.tcl.tk/man/tcl8.6/TclCmd/clock.html#M80 It sure looks like freebsd 13.2 tcl is just busted. Notably it can't even parse what it generates: echo 'puts [clock scan [clock format [clock seconds] -format "%Y/%m/%d"] -format "%Y/%m/%d"]'|tclsh8.6 Which works on 13.1 (and other operating systems), without a problem. I used truss as a very basic way to see differences between 13.1 and 13.2 - the big difference was .2 failing just after access("/etc/localtime",F_OK) ERR#2 'No such file or directory' open("/etc/localtime",O_RDONLY,077) ERR#2 'No such file or directory' whereas 13.1 also saw that, but then continued to issetugid() = 0 (0x0) open("/usr/share/zoneinfo/UTC",O_RDONLY,00) = 3 (0x3) fstat(3,{ mode=-r--r--r-- ,inode=351417,size=118,blksize=32768 }) = 0 (0x0) ... which made me test specifying the timezone explicitly: echo 'puts [clock scan [clock format [clock seconds] -format "%Y/%m/%d" -timezone "UTC"] -format "%Y/%m/%d" -timezone "UTC"]'|tclsh8.6 Which, surprise, works. So does specifying the timezone via the TZ='UTC' environment variable. I guess there could be a libc behaviour change or such around timezones? I do see https://www.freebsd.org/releases/13.2R/relnotes/ "tzcode has been upgraded to version 2022g with improved timezone change detection and reliability fixes." Greetings, Andres Freund
Hi,
On 2023-07-31 12:15:10 -0700, Andres Freund wrote:
> It sure looks like freebsd 13.2 tcl is just busted. Notably it can't even
> parse what it generates:
>
> echo 'puts [clock scan [clock format [clock seconds] -format "%Y/%m/%d"] -format "%Y/%m/%d"]'|tclsh8.6
>
> Which works on 13.1 (and other operating systems), without a problem.
>
> I used truss as a very basic way to see differences between 13.1 and 13.2 -
> the big difference was .2 failing just after
> access("/etc/localtime",F_OK) ERR#2 'No such file or directory'
> open("/etc/localtime",O_RDONLY,077) ERR#2 'No such file or directory'
>
> whereas 13.1 also saw that, but then continued to
>
> issetugid() = 0 (0x0)
> open("/usr/share/zoneinfo/UTC",O_RDONLY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=351417,size=118,blksize=32768 }) = 0 (0x0)
> ...
>
> which made me test specifying the timezone explicitly:
> echo 'puts [clock scan [clock format [clock seconds] -format "%Y/%m/%d" -timezone "UTC"] -format "%Y/%m/%d" -timezone
"UTC"]'|tclsh8.6
>
> Which, surprise, works.
>
> So does specifying the timezone via the TZ='UTC' environment variable.
>
>
> I guess there could be a libc behaviour change or such around timezones? I do
> see
> https://www.freebsd.org/releases/13.2R/relnotes/
> "tzcode has been upgraded to version 2022g with improved timezone change detection and reliability fixes."
One additional datapoint: If I configure the timezone with "tzsetup" (which
creates /etc/localtime), the problem vanishes as well.
Greetings,
Andres Freund
Andres Freund <andres@anarazel.de> writes:
> I saw that CI image builds for freebsd were failing, because 13.1, used until
> now, is EOL. Update to 13.2, no problem, I thought. Ran a CI run against 13.2
> - unfortunately that failed. In pltcl of all places.
I tried to replicate this in a freshly-installed 13.2 VM, and could
not, which is unsurprising because the FreeBSD installation process
does not let you skip selecting a timezone --- which creates
/etc/localtime AFAICT. So I'm unconvinced that we ought to worry
about the case where that's not there. How is it that the CI image
lacks that file? (And could it be that we had one in the predecessor
13.1 image?)
regards, tom lane
Hi,
On 2023-07-31 18:33:37 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I saw that CI image builds for freebsd were failing, because 13.1, used until
> > now, is EOL. Update to 13.2, no problem, I thought. Ran a CI run against 13.2
> > - unfortunately that failed. In pltcl of all places.
>
> I tried to replicate this in a freshly-installed 13.2 VM, and could
> not, which is unsurprising because the FreeBSD installation process
> does not let you skip selecting a timezone --- which creates
> /etc/localtime AFAICT. So I'm unconvinced that we ought to worry
> about the case where that's not there. How is it that the CI image
> lacks that file?
I don't know why it lacks the file - the CI image is based on the google cloud
image freebsd maintains / publishes ([1][2]). Which doesn't have /etc/localtime.
I've now added a "tzsetup UTC" to the image generation, which fixes the test
failure.
> (And could it be that we had one in the predecessor 13.1 image?)
No, I checked, and it's not in there either... It looks like the difference is
that 13.1 reads the UTC zoneinfo in that case, whereas 13.2 doesn't.
Upstream 13.1 image:
truss date 2>&1|grep -E 'open|stat'
...
open("/etc/localtime",O_RDONLY,0101401200) ERR#2 'No such file or directory'
open("/usr/share/zoneinfo/UTC",O_RDONLY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=351417,size=118,blksize=32768 }) = 0 (0x0)
open("/usr/share/zoneinfo/posixrules",O_RDONLY,014330460400) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=356621,size=3535,blksize=32768 }) = 0 (0x0)
fstat(1,{ mode=p--------- ,inode=696,size=0,blksize=4096 }) = 0 (0x0)
Upstream 13.2 image:
open("/etc/localtime",O_RDONLY,01745) ERR#2 'No such file or directory'
fstat(1,{ mode=p--------- ,inode=658,size=0,blksize=4096 }) = 0 (0x0)
Why not reading the UTC zone leads to timestamps being out of range, I do not
know...
Greetings,
Andres Freund
[1] https://wiki.freebsd.org/GoogleCloudPlatform
[2] https://cloud.google.com/compute/docs/images#freebsd
Andres Freund <andres@anarazel.de> writes:
> On 2023-07-31 18:33:37 -0400, Tom Lane wrote:
>> (And could it be that we had one in the predecessor 13.1 image?)
> No, I checked, and it's not in there either... It looks like the difference is
> that 13.1 reads the UTC zoneinfo in that case, whereas 13.2 doesn't.
Huh. Maybe worth reporting as a FreeBSD bug? In any case I don't
think it's *our* bug.
regards, tom lane
Hi, On 2023-07-31 19:11:38 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2023-07-31 18:33:37 -0400, Tom Lane wrote: > >> (And could it be that we had one in the predecessor 13.1 image?) > > > No, I checked, and it's not in there either... It looks like the difference is > > that 13.1 reads the UTC zoneinfo in that case, whereas 13.2 doesn't. > > Huh. Maybe worth reporting as a FreeBSD bug? Yea. Hoping our local freebsd developer has a suggestion as to which component to report it to, or even fix it :). > In any case I don't think it's *our* bug. Agreed. An explicit tzsetup UTC isn't much to carry going forward... Greetings, Andres Freund
Andres Freund <andres@anarazel.de> writes:
> On 2023-07-31 19:11:38 -0400, Tom Lane wrote:
>> Huh. Maybe worth reporting as a FreeBSD bug?
> Yea. Hoping our local freebsd developer has a suggestion as to which component
> to report it to, or even fix it :).
You already have a reproducer using just tcl, so I'd suggest filing
it against tcl and letting them drill down as needed. (It's possible
that it actually is tcl that's misbehaving, seeing that our core
regression tests are passing in the same environment.)
regards, tom lane