Re: CVS trunk testing results (PowerBook G4 MacOS X - 10.2.8)

Hi all,

The getdate.y module is failing near the UNIX epoch on Mac OS X, but
only when TZ=UTC.  For example, entering either "1970-01-01 2:00:00
-0400" or "1970-01-01 2:00:00 +0400" with TZ=UTC on OS X will yield the
output "1970-01-01 02:00:00.000000000", which I would hazard is
obviously incorrect for any single given local timezone.

Has anyone heard of anything like this before?  I can't find anything on
UTC bugs in OSX on Google and my reading and rereading of the complex
getdate.y code hasn't given me any inspiration.

Again, the UTC timezone seems to be fine in most cases and even times
near the epoch work fine with TZ=-0800.  My test script is attached
which exercises the UTC issues.  The script passes on most systems and
all the times tested except the two mentioned above even pass on OS X. 
The attached message below contains transcripts of sessions showing both
the offending times working with TZ=-0800 and broken TZ=UTC tests with
yydebug output.

My next step is to try and get access to the machine (it's not mine) and
step through with a debugger or possibly get an accomplice to do the
same, but I thought someone here might have some clue as to what could
be wrong.

Thanks,

Derek

Mark D. Baushke wrote:

> Derek Robert Price <[email protected]> writes:
>
> >Mark D. Baushke wrote:
>
> >>Recompiling with '#define YYDEBUG' in config.h and setting yydebug=1
> >>in a run yeilds the following information
>
>
> >[snip]
>
> >>Enter date, or blank line to exit.
> >>        > 1970-01-01 2:00:00 -0400
>
>
> >[snip]
>
> >>1969-12-31 22:00:00.000000000
> >>        > 1970-01-01 2:00:00 +0400
>
>
> >[snip]
>
> >>1969-12-31 14:00:00.000000000
>
>
> >These two results are actually correct, given a TZ=-0800 rather than
> >TZ=UTC, as the script sets, as the final result is output in local
> >time.  Your debug output also matched mine from Linux for both inputs
> >and matching the info against getdate.y, it looks like the timezone is
> >being parsed correctly.
>
> >Perhaps OS X is dealing badly with `TZ'?  The script does `TZ=UTC;
> >export TZ'.  This thought had occurred to me when I was reading your
> >original report, but the error is different depending on the specified
> >timezone and I had discounted it, but I guess OS X could be doing
> >something really odd.  Since 1970-01-01 2:00:00 -0400 and 1970-01-01
> >2:00:00 +0400 yield the same result of 1970-01-01 2:00:00 UTC in your
> >original report, "really odd" must mean a variable error since it is
> >off by +0400 in the first case and -0400 hours in the second.
>
> >Perhaps a gdb run of the getdate program with TZ=UTC would be
> informative?
>
>
> I have some other things to work on today, so I can't look closely at
> this right now...
>
>     -- Mark
>
> Script started on Mon Nov  8 21:56:51 2004
> $ date
> Mon Nov  8 21:56:56 UTC 2004
> $ echo $TZ
> UTC
> $ gdb getdate
> GNU gdb 5.3-20021014 (Apple version gdb-250) (Sat Dec  7 02:14:27 GMT
> 2002)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "powerpc-apple-macos10".
> Reading symbols for shared libraries ... done
> (gdb) b main
> Breakpoint 1 at 0x4e38: file getdate.y, line 1374.
> (gdb) run
> Starting program: /Users/mdb/src/cvs/ccvs-trunk/ccvs/obj.test/lib/getdate
> [Switching to process 9966 thread 0xb03]
> Reading symbols for shared libraries . done
> Reading symbols for shared libraries ................ done
>
> Breakpoint 1, main (ac=1, av=0xbffffb70) at getdate.y:1374
> 1374    getdate.y: No such file or directory.
>     in getdate.y
> (gdb) set yydebug=1
> (gdb) cont
> Continuing.
> Enter date, or blank line to exit.


[snip]

>     > 1970-01-01 2:00:00 +0400
> Starting parse
> Entering state 0
> Reading a token: Next token is token tUNUMBER ()
> Reducing stack by rule 4 (line 212), -> items
> Stack now 0
> Entering state 4
> Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 25
> Reading a token: Next token is token tSNUMBER ()
> Shifting token tSNUMBER, Entering state 57
> Reading a token: Next token is token tSNUMBER ()
> Shifting token tSNUMBER, Entering state 67
> Reducing stack by rule 28 (line 338), tUNUMBER tSNUMBER tSNUMBER -> date
> Stack now 0 4
> Entering state 33
> Reducing stack by rule 9 (line 224), date -> item
> Stack now 0 4
> Entering state 28
> Reducing stack by rule 5 (line 214), items item -> items
> Stack now 0
> Entering state 4
> Reading a token: Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 25
> Reading a token: Next token is token ':' ()
> Shifting token ':', Entering state 58
> Reading a token: Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 68
> Reading a token: Next token is token ':' ()
> Shifting token ':', Entering state 73
> Reading a token: Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 6
> Reducing stack by rule 62 (line 452), tUNUMBER -> unsigned_seconds
> Stack now 0 4 25 58 68 73
> Entering state 76
> Reading a token: Next token is token tSNUMBER ()
> Shifting token tSNUMBER, Entering state 78
> Reducing stack by rule 17 (line 267), tUNUMBER ':' tUNUMBER ':'
> unsigned_seconds tSNUMBER -> time
> Stack now 0 4
> Entering state 29
> Reducing stack by rule 6 (line 218), time -> item
> Stack now 0 4
> Entering state 28
> Reducing stack by rule 5 (line 214), items item -> items
> Stack now 0
> Entering state 4
> Reading a token: Now at end of input.
> Reducing stack by rule 2 (line 201), items -> spec
> Stack now 0
> Entering state 2
> Now at end of input.
> 1970-01-01 02:00:00.000000000


[snip]

>     > 1970-01-01 2:00:00 -0400
> Starting parse
> Entering state 0
> Reading a token: Next token is token tUNUMBER ()
> Reducing stack by rule 4 (line 212), -> items
> Stack now 0
> Entering state 4
> Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 25
> Reading a token: Next token is token tSNUMBER ()
> Shifting token tSNUMBER, Entering state 57
> Reading a token: Next token is token tSNUMBER ()
> Shifting token tSNUMBER, Entering state 67
> Reducing stack by rule 28 (line 338), tUNUMBER tSNUMBER tSNUMBER -> date
> Stack now 0 4
> Entering state 33
> Reducing stack by rule 9 (line 224), date -> item
> Stack now 0 4
> Entering state 28
> Reducing stack by rule 5 (line 214), items item -> items
> Stack now 0
> Entering state 4
> Reading a token: Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 25
> Reading a token: Next token is token ':' ()
> Shifting token ':', Entering state 58
> Reading a token: Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 68
> Reading a token: Next token is token ':' ()
> Shifting token ':', Entering state 73
> Reading a token: Next token is token tUNUMBER ()
> Shifting token tUNUMBER, Entering state 6
> Reducing stack by rule 62 (line 452), tUNUMBER -> unsigned_seconds
> Stack now 0 4 25 58 68 73
> Entering state 76
> Reading a token: Next token is token tSNUMBER ()
> Shifting token tSNUMBER, Entering state 78
> Reducing stack by rule 17 (line 267), tUNUMBER ':' tUNUMBER ':'
> unsigned_seconds tSNUMBER -> time
> Stack now 0 4
> Entering state 29
> Reducing stack by rule 6 (line 218), time -> item
> Stack now 0 4
> Entering state 28
> Reducing stack by rule 5 (line 214), items item -> items
> Stack now 0
> Entering state 4
> Reading a token: Now at end of input.
> Reducing stack by rule 2 (line 201), items -> spec
> Stack now 0
> Entering state 2
> Now at end of input.
> 1970-01-01 02:00:00.000000000



-- 
                *8^)

Email: [email protected]

Get CVS support at <http://ximbiot.com>!

_______________________________________________
Bug-gnulib mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-gnulib

#! /bin/sh

# Test that a getdate executable meets its specification.
#
# Copyright (C) 2004 Free Software Foundation, Inc.
#
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 2, or (at your option)
# any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program; if not, write to the Free Software Foundation,
# Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  */

# Why are these dates tested?
#
# February 29, 2003
#   Is not a leap year - should be invalid.
#
# 2004-12-40
#   Make sure get_date does not "roll" date forward to January 9th.  Some
#   versions have been known to do this.
#
# Dec-5-1972
#   This is my birthday.  :)
#
# 3/29/1974
# 1996/05/12 13:57:45
#   Because.
#
# 12-05-12
#   This will be my 40th birthday.  Ouch.  :)
#
# 05/12/96
#   Because.
#
# third tuesday in March, 2078
#   Wanted this to work.
#
# 1969-12-32 2:00:00 UTC
# 1970-01-01 2:00:00 UTC
# 1969-12-32 2:00:00 +0400
# 1970-01-01 2:00:00 +0400
# 1969-12-32 2:00:00 -0400
# 1970-01-01 2:00:00 -0400
#   Playing near the UNIX Epoch boundry condition to make sure date rolling
#   is also disabled there.
#
# 1996-12-12 1 month
#   Test a relative date.
#
# Feb. 29, 2096 8 years
#   8 years from this date is _not_ a leap year, so Feb. 29th does not exist.

TZ=UTC; export TZ

cat >getdate-expected <<EOF
Enter date, or blank line to exit.
	> Bad format - couldn't convert.
	> Bad format - couldn't convert.
	> 1972-12-05 00:00:00.000000000
	> 1974-03-29 00:00:00.000000000
	> 1996-05-12 13:57:45.000000000
	> 2012-05-12 00:00:00.000000000
	> 1996-05-12 00:00:00.000000000
	> Bad format - couldn't convert.
	> Bad format - couldn't convert.
	> 1970-01-01 02:00:00.000000000
	> Bad format - couldn't convert.
	> 1969-12-31 22:00:00.000000000
	> Bad format - couldn't convert.
	> 1970-01-01 06:00:00.000000000
	> 1997-01-12 00:00:00.000000000
	> Bad format - couldn't convert.
	> 
EOF

./getdate >getdate-got <<EOF
February 29, 2003
2004-12-40
Dec-5-1972
3/29/1974
1996/05/12 13:57:45
12-05-12
05/12/96
third tuesday in March, 2078
1969-12-32 2:00:00 UTC
1970-01-01 2:00:00 UTC
1969-12-32 2:00:00 +0400
1970-01-01 2:00:00 +0400
1969-12-32 2:00:00 -0400
1970-01-01 2:00:00 -0400
1996-12-12 1 month
Feb. 29, 2096 8 years
EOF

echo >>getdate-got

if cmp getdate-expected getdate-got >getdate.cmp; then :; else
	LOGFILE=`pwd`/getdate.log
	cat getdate.cmp >${LOGFILE}
	echo "** expected: " >>${LOGFILE}
	cat getdate-expected >>${LOGFILE}
	echo "** got: " >>${LOGFILE}
	cat getdate-got >>${LOGFILE}
	echo "FAIL: getdate" | tee -a ${LOGFILE}
	echo "Failed!  See ${LOGFILE} for more!" >&2
	exit 1
fi

rm getdate-expected getdate-got getdate.cmp
exit 0

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBki+pLD1OTBfyMaQRAtfEAJ4xjFSORhWt/cs6ohuT2igvD9pf2gCgqzL+
EUBTfL0adLKuJ5gBrEMm9FU=
=AdSB
-----END PGP SIGNATURE-----