GNU bug report logs - #19799
Tangentally related to eww-mode Invalid Date bug just filed

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 19799 in the body.
You can then email your comments to 19799 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Matthew Carter <m <at> ahungry.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Tangentally related to eww-mode Invalid Date bug just filed
Date: Sat, 07 Feb 2015 00:15:55 -0500

Excuse the new thread (just signed up to bug-gnu-emacs list, whereas I
filed the original bug via the report function).

I've pinpointed the eww-mode bug to an issue with #'date-to-time in
time-date.el.

It appears to be a manifestation of the Year 2038 problem and caused by
the fact that the cookie being sent has an expiration date beyond year
2038.

As it turns out, I am unable to reproduce the issue on a 64-bit machine
(it only happens on my 32-bit ones).

Would it be better to rework #'date-to-time to handle future dates in a
more graceful manner on 32-bit machines, or to have eww-mode ignore
triggers that cause it to parse dates it cannot handle?

-- 
Matthew Carter (m <at> ahungry.com)
http://ahungry.com

Message #8 received at 19799 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Matthew Carter <m <at> ahungry.com>
Cc: 19799 <at> debbugs.gnu.org
Subject: Re: Tangentally related to eww-mode Invalid Date bug just filed
Date: Sun, 08 Feb 2015 11:28:52 -0800

> Would it be better to rework #'date-to-time to handle future dates in a
> more graceful manner on 32-bit machines, or to have eww-mode ignore
> triggers that cause it to parse dates it cannot handle?

There is a variant of date-to-time that refuses to throw an error on 
out-of-range dates, namely safe-date-to-time.  But I'm still puzzled as to why 
you're getting this error.  date-to-time is supposed to throw a "Specified time 
is not representable" for out-of-range dates, but for you it's throwing some 
other error.  Can you debug why that is happening?

What happens when you run the following in your *scratch* buffer?

(date-to-time "Mon, 06 Mar 2130 20:55:03 GMT")

On my platform (Fedora 21 x86) if I type C-j after that, the debugger is entered 
with this backtrace:

Debugger entered--Lisp error: (error . "Specified time is not representable")
  signal(error "Specified time is not representable")
  apply(signal (error "Specified time is not representable"))
  (if (equal err overflow-error) (apply (quote signal) err) (condition-case err$
  (let ((overflow-error (quote (error "Specified time is not representable"))))$
  (condition-case err (apply (quote encode-time) (parse-time-string date)) (err$
  date-to-time("Mon, 06 Mar 2130 20:55:03 GMT")
  ...

What happens on your platform?

Also, what is your platform?  What does (emacs-version) return, for starters?

Message #11 received at 19799 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Carter <m <at> ahungry.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 19799 <at> debbugs.gnu.org
Subject: Re: Tangentally related to eww-mode Invalid Date bug just filed
Date: Sun, 08 Feb 2015 15:25:23 -0500

Paul Eggert <eggert <at> cs.ucla.edu> writes:

>> Would it be better to rework #'date-to-time to handle future dates in a
>> more graceful manner on 32-bit machines, or to have eww-mode ignore
>> triggers that cause it to parse dates it cannot handle?
>
> There is a variant of date-to-time that refuses to throw an error on
> out-of-range dates, namely safe-date-to-time.  But I'm still puzzled
> as to why you're getting this error.  date-to-time is supposed to
> throw a "Specified time is not representable" for out-of-range dates,
> but for you it's throwing some other error.  Can you debug why that is
> happening?
>
> What happens when you run the following in your *scratch* buffer?
>
> (date-to-time "Mon, 06 Mar 2130 20:55:03 GMT")
>
> On my platform (Fedora 21 x86) if I type C-j after that, the debugger
> is entered with this backtrace:
>
> Debugger entered--Lisp error: (error . "Specified time is not representable")
>   signal(error "Specified time is not representable")
>   apply(signal (error "Specified time is not representable"))
>   (if (equal err overflow-error) (apply (quote signal) err) (condition-case err$
>   (let ((overflow-error (quote (error "Specified time is not representable"))))$
>   (condition-case err (apply (quote encode-time) (parse-time-string date)) (err$
>   date-to-time("Mon, 06 Mar 2130 20:55:03 GMT")
>   ...
>
> What happens on your platform?
>
> Also, what is your platform?  What does (emacs-version) return, for starters?
>

This is on an i686 machine - the eval returns:

Debugger entered--Lisp error: (error "Invalid date: Mon, 06 Mar 2130 20:55:03 GMT")
  signal(error ("Invalid date: Mon, 06 Mar 2130 20:55:03 GMT"))
  error("Invalid date: %s" "Mon, 06 Mar 2130 20:55:03 GMT")
  byte-code("\300\301\302\217\207" [nil (byte-code "\301\302\303\304^H!!\"\207" [date apply encode-time parse-time-string time$
  date-to-time("Mon, 06 Mar 2130 20:55:03 GMT")
  eval((date-to-time "Mon, 06 Mar 2130 20:55:03 GMT") nil)
  eval-last-sexp-1(t)
  eval-last-sexp(t)
  eval-print-last-sexp(nil)
  call-interactively(eval-print-last-sexp nil nil)
  command-execute(eval-print-last-sexp)

The version is:

GNU Emacs 24.4.1 (i686-pc-linux-gnu, GTK+ Version 3.14.7) of 2015-01-17 on bisson

Anything up to 2038 will work without issue.  I had read OpenBSD fixed
the 2038 date issue using 'long long int' instead of 'time_t' for dates
in the codebase on 32 bit machines.

I think eww-mode should not fail to load subsequent pages though, even
if a cookie date is bad (bad cookies should not halt further page
requests), so maybe eww-mode just needs to catch the thrown error?

-- 
Matthew Carter (m <at> ahungry.com)
http://ahungry.com

Message #16 received at 19799-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Matthew Carter <m <at> ahungry.com>
Cc: 19799-done <at> debbugs.gnu.org
Subject: Re: Tangentally related to eww-mode Invalid Date bug just filed
Date: Sun, 08 Feb 2015 18:50:41 -0800

OK, I've fixed the "Invalid date:" bug in master commit 
fd6f7d1449c8496ab5c019d2aad7ca5e2980713a dated today.  This fixes the problem 
with date-to-time on 32-bit hosts, since it now throws the correct exception 
rather than the incorrect one, so I'm closing this bug report.  I'm leaving 
Bug#19798 open for now, until you can verify that the original eww issue is 
indeed fixed on the master.

Message #19 received at 19799 <at> debbugs.gnu.org (full text, mbox):

From: Matthew Carter <m <at> ahungry.com>
To: 19799 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu
Subject: Re: bug#19799: Tangentally related to eww-mode Invalid Date bug just
 filed
Date: Sun, 08 Feb 2015 22:14:25 -0500

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> OK, I've fixed the "Invalid date:" bug in master commit
> fd6f7d1449c8496ab5c019d2aad7ca5e2980713a dated today.  This fixes the
> problem with date-to-time on 32-bit hosts, since it now throws the
> correct exception rather than the incorrect one, so I'm closing this
> bug report.  I'm leaving Bug#19798 open for now, until you can verify
> that the original eww issue is indeed fixed on the master.
>
>
>

The issue is fixed, no more failure to load subsequent pages when an
overflowed cookie date is encountered.

Thanks!

-- 
Matthew Carter (m <at> ahungry.com)
http://ahungry.com

Message #22 received at 19799 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Matthew Carter <m <at> ahungry.com>
Cc: 19799 <at> debbugs.gnu.org, 19798-done <at> debbugs.gnu.org
Subject: Re: bug#19799: Tangentally related to eww-mode Invalid Date bug just
 filed
Date: Sun, 08 Feb 2015 22:29:37 -0800

Matthew Carter wrote:

> The issue is fixed, no more failure to load subsequent pages when an
> overflowed cookie date is encountered.

Thanks for checking, and so I'm closing Bug#19798 too.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.