On 14/01/16 03:37, Pádraig Brady wrote: > On 13/01/16 18:30, Pádraig Brady wrote: >> On 13/01/16 17:29, Assaf Gordon wrote: >>
>>> freebsd101-test-suite.log >>> >>> FAIL: tests/misc/head-c >>> ======================= >>> >>> + page_size=4096 >>> + page_size=4 >> >>> + ulimit -v 10000 >>> + head -c1 /dev/null >>> Segmentation fault (core dumped) >> >> Hmm, we should also be disabling core dumps >> for this ulimit -v determination, with something like? >> >> trap '' SEGV; ulimit -c 0; > > Patch attached s/ulimit_supported/ulimit_supported_/ typo fixed in that >>> + ulimit -v 14004 >>> + head --bytes=-9223372036854775807 >>> head: memory exhausted >> >> Does the test pass when changing s/1000/2000/ on the ulimit line? Yes it does. In fact 1.576MB over the base determined value was needed. I've bumped the value to $base+4000 While testing on FreeBSD 10 I also hit an issue that Assaf hit previously: https://lists.gnu.org/archive/html/coreutils/2014-07/msg00116.html Attached is a patch to comment out the test with an explanation, as it makes invalid assumptions that perl actually calls localtime(). Related to that I pushed a doc patch to gnulib on the localtime issue: http://git.sv.gnu.org/gitweb/?p=gnulib.git;a=commitdiff;h=95c48427 cheers, Pádraig
From 3aa84d02ddd22dc9430275f544cb435d64c5e385 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?P=C3=A1draig=20Brady?= <[email protected]> Date: Fri, 15 Jan 2016 15:56:30 +0000 Subject: [PATCH] tests: remove a non portable localtime test * tests/misc/date.pl: This test was dependent on perl unconditionally calling the system localtime() as date(1) does. However perl has its own configure checks in place to avoid buggy localtime implementations. Therefore comment out this test as a FIXME for now. This test was seen to fail on FreeBSD 10 where localtime() returns nonsense values instead of failing for arguments >= 2^56. --- tests/misc/date.pl | 48 ++++++++++++++++++------------------------------ 1 file changed, 18 insertions(+), 30 deletions(-) diff --git a/tests/misc/date.pl b/tests/misc/date.pl index 9f09c69..2d19254 100755 --- a/tests/misc/date.pl +++ b/tests/misc/date.pl @@ -42,20 +42,6 @@ my $dy = '1998-01-19'; # next month my $fmt = "'+%Y-%m-%d %T'"; -# Determine a number of seconds that will provoke an invalid -# time diagnostic from date. If possible, use a number that -# is less than 2^64, yet so large that it would cause the resulting -# tm_year value to be too large for a 32-bit int. But some systems -# (Solaris 8) have a buggy localtime that mistakenly accepts such -# invalid times and give garbage in tm_year. Other systems might -# have an int type that is wider than 32. So if this localtime -# call succeeds, use 2^64 as the number of seconds. -my $n_seconds = 72057594037927935; -my @d = localtime ($n_seconds); -my $year = $d[5]; -defined $year - and $n_seconds = '18446744073709551616'; - my @Tests = ( # test-name, [option, option, ...] {OUT=>"expected-output"} @@ -255,22 +241,24 @@ my @Tests = ['neg-secs', '-d @-22 +%05s', {OUT=>"-0022"}], ['neg-secs2', '-d @-22 +%_5s', {OUT=>" -22"}], - # Before today's fix, date would print uninitialized data - # to standard output for an out-of-range date: - # $ date -d @$(echo 2^56-1|bc) 2> /dev/null | od -a -N3 - # 0000000 p 4 6 - # 0000003 - ['uninit-64', "-d \@$n_seconds", - {OUT=>''}, - # Use ERR_SUBST to get around fact that the diagnostic - # you get on a system with 32-bit time_t is not the same as - # the one you get for a system where it's 64 bits wide: - # - date: time 72057594037927935 is out of range - # + date: invalid date '@72057594037927935' - {ERR_SUBST => 's/.*//'}, - {ERR => "\n"}, - {EXIT => 1}, - ], + # FIXME: Ensure date doesn't print uninitialized data + # for an out-of-range date. This test is currently + # disabled as various systems have different limits + # for localtime(), and we can't use perl for example + # to determine those limits as it doesn't always call + # down to the system localtime() as it has configure + # time checks and settings itself for these limits. + #['uninit-64', "-d \@72057594037927935", + # {OUT=>''}, + # # Use ERR_SUBST to get around fact that the diagnostic + # # you get on a system with 32-bit time_t is not the same as + # # the one you get for a system where it's 64 bits wide: + # # - date: time 72057594037927935 is out of range + # # + date: invalid date '@72057594037927935' + # {ERR_SUBST => 's/.*//'}, + # {ERR => "\n"}, + # {EXIT => 1}, + #], ['fill-1', '-d 1999-12-08 +%_3d', {OUT=>' 8'}], ['fill-2', '-d 1999-12-08 +%03d', {OUT=>'008'}], -- 2.5.0
