[Bug-gnulib] Re: CVS trunk testing results (PowerBook G4 MacOS X - 10.2.8)

[Derek Robert Price]

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 <address@hidden> 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: address@hidden

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

test-getdate.sh
Description: Bourne shell script

signature.asc
Description: OpenPGP digital signature