in reply to Perl release v5.40.1 on a 32-bit box showing failed tests for atime and ctime in Time::HiRes

Perl (including Time::HiRES) is regularly tested against a 32-bit Linux userland, and Debian still provide 32-bit installation images.

That Debian version number looks strange, I only ever recall seeing major.minor versions for Debian. If it is Debian you should have a /etc/debian_version file with the release number.

You can run just the failing test with:

./perl harness -v ../dist/Time-HiRes/t/utime.t

which may provide some clues as to what's going on.

You say you're using the latest Debian archive, do you see the same failure if you build from the origin perl 5.40.1 sources?

  • Comment on Re: Perl release v5.40.1 on a 32-bit box showing failed tests for atime and ctime in Time::HiRes
  • Select or Download Code

Replies are listed 'Best First'.
Re^2: Perl release v5.40.1 on a 32-bit box showing failed tests for atime and ctime in Time::HiRes
by Intrepid (Curate) on Mar 06, 2025 at 19:59 UTC

    Hey tonyc. Thanks, you taught me something. I ran ./perl harness -v ../dist/Time-HiRes/t/utime.t and the output (trimmed out a little bit of non-relevant stuff for readability):

    ../dist/Time-HiRes/t/utime.t .. 

# Testing for subsecond file timestamps (mtime) in /home/somian/build/perl/perl-debian-5.40/dist/Time-HiRes
# Subsecond file timestamps in /home/somian/build/perl/perl-debian-5.40/dist/Time-HiRes: OK
1..22
# $^O = linux, atime = 1.111111111, mtime = 2.222222222
# utime $fh
ok 1 - One file changed
not ok 2 - atime set correctly

#   Failed test 'atime set correctly'
#   at t/utime.t line 156.
#          got: '1'
#     expected: '1.111111111'
not ok 3 - mtime set correctly

#   Failed test 'mtime set correctly'
#   at t/utime.t line 158.
#          got: '2'
#     expected: '2.222222222'
#utime $filename
ok 4 - One file changed
not ok 5 - atime set correctly

#   Failed test 'atime set correctly'
#   at t/utime.t line 168.
#          got: '1'
#     expected: '1.111111111'
not ok 6 - mtime set correctly

#   Failed test 'mtime set correctly'
#   at t/utime.t line 170.
#          got: '2'
#     expected: '2.222222222'
#utime $filename round-trip
ok 7 - One file changed
ok 8 - One file changed
ok 9 - atime round trip ok
ok 10 - mtime round trip ok
utime $filename and $fh
ok 11 - Two files changed
not ok 12 - File 1 atime set correctly

#   Failed test 'File 1 atime set correctly'
#   at t/utime.t line 195.
#          got: '1'
#     expected: '1.111111111'
not ok 13 - File 1 mtime set correctly

#   Failed test 'File 1 mtime set correctly'
#   at t/utime.t line 197.
#          got: '2'
#     expected: '2.222222222'
not ok 14 - File 2 atime set correctly

#   Failed test 'File 2 atime set correctly'
#   at t/utime.t line 203.
#          got: '1'
#     expected: '1.111111111'
not ok 15 - File 2 mtime set correctly

#   Failed test 'File 2 mtime set correctly'
#   at t/utime.t line 205.
#          got: '2'
#     expected: '2.222222222'
# utime undef sets time to now
ok 16 - Two files changed
ok 17 - File 1 atime set correctly
ok 18 - File 1 mtime set correctly
ok 19 - File 2 atime set correctly
ok 20 - File 2 mtime set correctly
# negative atime dies
ok 21 - negative time error
# negative mtime dies;
ok 22 - negative time error
# Looks like you failed 8 tests of 22.
Dubious, test returned 8 (wstat 2048, 0x800)
Failed 8/22 subtests 

Test Summary Report
-------------------
../dist/Time-HiRes/t/utime.t (Wstat: 2048 (exited 8) Tests: 22 Failed: 8)
  Failed tests:  2-3, 5-6, 12-15
  Non-zero exit status: 8
Files=1, Tests=22,  1 wallclock secs ( 0.02 usr  0.01 sys +  0.22 cusr  0.03 csys =  0.28 CPU)
Result: FAIL
Finished test run at Thu Mar  6 13:54:43 2025.

    It seems that the test code expected floats but got integers.

    WRT the version of Debian I am running, I derived the version I reported in my post from the output of cat /proc/version, but the /etc/debian_version file contains 12.1. Hope that clarifies things.

    Thanks again.

    Mar 06, 2025 at 19:54 UTC
[reply]
[d/l]
[select]

      From your other comment you're using ext4, so I'd expect the file system to support sub-second timestamps, if you do:

      # this is a command-line command, not perl code
stat .

      [download]

      does it show sub-second timestamps, eg. I get

      $ stat .
  File: .
  Size: 20480           Blocks: 40         IO Block: 4096   directory
Device: 253,2   Inode: 33079540    Links: 26
Access: (0755/drwxr-xr-x)  Uid: ( 1000/    tony)   Gid: ( 1000/    ton
+y)
Access: 2025-03-10 07:39:22.352732987 +1100
Modify: 2025-03-06 15:07:42.145467132 +1100
Change: 2025-03-06 15:07:42.145467132 +1100
 Birth: 2022-08-08 15:04:51.515950529 +1000

      [download]
[reply]
[d/l]
[select]

        OK, let's see if we get sub-second times:

          File: .
  Size: 4096      	Blocks: 8          IO Block: 4096   directory
Device: 0,44	Inode: 38143619    Links: 3
Access: (0755/drwxr-xr-x)  Uid: ( 1000/  somian)   Gid: ( 1000/  somian)
Access: 2025-03-10 14:53:44.479709798 -0400
Modify: 2025-03-02 15:29:55.074591170 -0500
Change: 2025-03-02 15:29:55.074591170 -0500
 Birth: -

        Aside from not seeing Birth times for any directory or regular file, it seems that I am running ext4 and ext4 is behaving as expecting.

        Mar 12, 2025 at 02:23 UTC

        A just machine to make big decisions
        Programmed by fellows (and gals) with compassion and vision
        We'll be clean when their work is done
        We'll be eternally free yes, and eternally young
        Donald Fagen —> I.G.Y.
        (Slightly modified for inclusiveness)

[reply]

In Section Seekers of Perl Wisdom