-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
The correct place to report bugs in the getdate library would be
bug-gnulib@gnu.org, but could you please verify that you can reproduce
your problem with the version of CVS available from the CVS repository
on cvshome.org before you bother them? Also, see if you can `cd lib;
make getdate; ./getdate' and then enter your offending date at the
prompt provided. I cannot reproduce the problem you report using this
method, which might imply a problem with how we are using get_date
rather than with get_date itself, but then you should not have seen
problems from yyparse... anyway, please let us know what you discover.
Regards,
Derek
Ian Abbott wrote:
| Hi,
|
| I've just started having a problem with "cvs date -u" (version
| 1.12.11):
|
|
| cvs diff: Diffing . Index: ChangeLog cvs diff: internal error: bad
| date 7 Apr 2005 11:50:26 -0000
| ===================================================================
| RCS file: /work/abbotti/Repository/ampser/ChangeLog,v retrieving
| revision 1.66 *** glibc detected *** malloc(): memory corruption:
| 0x080eff60 *** cvs [diff aborted]: received abort signal
|
|
| I think the memory corruption is a side effect of the "bad date",
| so I'm concentrating on that for now. I've traced the problem as
| far as the 'get_date' function, called from 'RCS_getrevtime'.
| 'get_date' returned 'false', so 'RCS_getrevtime' never got as far
| as filling in the 'date' string for its caller.
|
| Some debugging info from gdb follows ....
|
| Value of 'pc' prior to the call to 'yyparse':
|
| (gdb) p pc $39 = {input = 0xbfffebe0 "2005-4-7 GMT 11:36:56",
| day_ordinal = 1073837632, day_number = 1075498996, local_isdst =
| -1073747276, time_zone = -1073747304, meridian = 2, year = {value =
| 2005, digits = 4}, month = 4, day = 7, hour = 14, minutes = 57,
| seconds = {tv_sec = 7, tv_nsec = 273590000}, rel_year = 0,
| rel_month = 0, rel_day = 0, rel_hour = 0, rel_minutes = 0,
| rel_seconds = 0, rel_ns = 0, timespec_seen = false, dates_seen = 0,
| days_seen = 0, local_zones_seen = 0, rels_seen = 0, times_seen = 0,
| zones_seen = 0, local_time_zone_table = {{ name = 0x80e3fb8 "BST",
| type = 264, value = 1}, { name = 0x80e4a70 "GMT", type = 264, value
| = 0}, { name = 0x0, type = 0, value = 0}}}
|
| Value of 'pc' after the call to 'yyparse':
|
| (gdb) p pc $40 = {input = 0xbfffebf6
|
"\uffff\uffff\017\203\033@0\uffff\032@\uffff\uffff\032@(\uffff\uffff\uffffO\uffff\016@
| \uffff\032@B", day_ordinal = 1073837632, day_number = 1075498996,
| local_isdst = 0, time_zone = -1073747304, meridian = 2, year =
| {value = 2005, digits = 4}, month = 4, day = 7, hour = 11, minutes
| = 36, seconds = {tv_sec = 56, tv_nsec = 0}, rel_year = 0, rel_month
| = 0, rel_day = 0, rel_hour = 0, rel_minutes = 0, rel_seconds = 0,
| rel_ns = 0, timespec_seen = false, dates_seen = 1, days_seen = 0,
| local_zones_seen = 1, rels_seen = 0, times_seen = 1, zones_seen =
| 0, local_time_zone_table = {{ name = 0x80e3fb8 "BST", type = 264,
| value = 1}, { name = 0x80e4a70 "GMT", type = 264, value = 0}, {
| name = 0x0, type = 0, value = 0}}}
|
| Values of 'Start', 'tm0' and 'tm' after the call to 'mktime':
|
| (gdb) p Start $46 = 1112873816 (gdb) p tm0 $47 = {tm_sec = 56,
| tm_min = 36, tm_hour = 11, tm_mday = 7, tm_mon = 3, tm_year = 105,
| tm_wday = 1075497952, tm_yday = 0, tm_isdst = 0, tm_gmtoff =
| 1075498996, tm_zone = 0x0} (gdb) p tm $48 = {tm_sec = 56, tm_min =
| 36, tm_hour = 12, tm_mday = 7, tm_mon = 3, tm_year = 105, tm_wday =
| 4, tm_yday = 96, tm_isdst = 1, tm_gmtoff = 3600, tm_zone =
| 0x80e3fb8 "BST"}
|
| The following call to 'mktime_ok' returns 0 because tm_hour has
| changed. This causes 'get_time' to 'goto fail' and return 'false'
| because pc.zones_seen == 0.
|
| Hopefully, there's enough info there for some bright spark to spot
| the problem, but let me know if you need more info.
|
| Cheers, Ian.
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFCVXZ3LD1OTBfyMaQRAjRGAJ9TS6wpLPGB0GL6q7ut3uv7cKoqdACg1iUR
ffyBVz1ylkvO8wyUk7rlx/Q=
=4OnW
-----END PGP SIGNATURE-----