bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#37974: eww produces "error in process filter: Specified time is not


From: A.C.
Subject: bug#37974: eww produces "error in process filter: Specified time is not representable"
Date: Tue, 29 Oct 2019 08:05:57 -0400
User-agent: K-9 Mail for Android

This must be a word-size issue: on *all* systems where

M-x eww RET arxiv.org RET

loads all right the largest n such that *scratch* evaluation of

(format-time-string "%a %b %d %H:%M:%S %Y GMT" (list n 0 0 0))

produces a valid date is

n=1034058169428

(exact same n on two x86_64 machines and an aarch64 Android phone). Also, all of these systems return

$ getconf WORD_BIT
32
$ getconf LONG_BIT
64

On the other hand, the Debian i686 system that doesn't load arxiv.org has a largest valid n of

n=32767=2**15-1

and returns

$ getconf WORD_BIT
32
$ getconf LONG_BIT
32

That's why it chokes on arxiv.org: loading that page attempts

format-time-string("%a %b %d %H:%M:%S %Y GMT" (38428 13130 924849 611000) t)

and 38428 > 32767

I don't know that upgrading to Emacs 26.3 from 26.1 would address this in any way.



On October 29, 2019 6:25:22 AM EDT, Stuart Little <achirvasub@gmail.com> wrote:
I believe I've isolated this as far as I can: the systems running Emacs 26.1 and 26.3 respectively have identical code for the function 'url-cookie-handle-set-cookie', so that on its own is not the problem. Rather, 'format-time-string' works fine on the x86_64 Arch Linux system but not the Debian i686:

On the former, evaluating

(format-time-string "%a %b %d %H:%M:%S %Y GMT" '(38428 5755 960288 499000))

in the *scratch* buffer echoes "Thu Oct 21 05:59:23 2049 GMT". On the other hand, evaluating the exact same function in the *scratch* buffer on the Debian system produces the error "Specified time is not representable".

On Tue, Oct 29, 2019 at 12:51:02AM -0400, Stuart Little wrote:
Apologies for the uninformative message below. I know slightly more now.

Setting debug-on-error and running

M-x eww RET arxiv.org RET

again produces the following trace:

--- cut here ---

Debugger entered--Lisp error: (error "Specified time is not representable")
format-time-string("%a %b %d %H:%M:%S %Y GMT" (38427 52290 103040 624000) t)
url-cookie-handle-set-cookie("browser=68.133.6.220.1572324160979722; path=/; max-age=946080000; domain=.arxiv.org")
url-http-handle-cookies()
url-http-parse-headers()
url-http-chunked-encoding-after-change-function(7029 7034 5)
url-http-generic-filter(#<process arxiv.org<1>> "0\015\n\015\n")
read-event(nil t 2)
sit-for(2)
execute-extended-command(nil "eww" "eww")
funcall-interactively(execute-extended-command nil "eww" "eww")
call-interactively(execute-extended-command nil nil)
command-execute(execute-extended-command)

--- done ---

This told me the problem was with the url-cookie-handle-set-cookie function; specifically, with the format-time-string directive therein. I tried to fiddle with it to confirm. Indeed, replacing the relevant if-then-else clause

--- cut ---

(if (and max-age (string-match "\\`-?[0-9]+\\'" max-age))
(setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT"
(time-add nil (read max-age))
t))
(setq expires (cdr-safe (assoc-string "expires" args t))))

--- done ---

therein with just the else branch

(setq expires (cdr-safe (assoc-string "expires" args t)))

resolves the issue. arxiv.org loads fine with the redefined url-cookie-handle-set-cookie function.

On Mon, Oct 28, 2019 at 08:32:45PM -0400, Stuart Little wrote:
I am on a Debian 10.1 machine i686. The current Emacs version in this Debian repo is 26.1.

My issue is that

M-x eww RET arxiv.org RET

fails to load the page and produces the error

error in process filter: Specified time is not representable

in the minibuffer. Other websites load fine (e.g. nytimes.com, theguardian.comn, google.com). Others, on the other hand, simply silently time out: duckduckgo.com and thenation.com behave this way (the minibuffer reports 'contacting host' but the page never loads).

Everything loads fine on an Arch Linux x86_64 machine running Emacs 26.3 as well as an Android 9 phone running an ARM version of Emacs 26.3 in a terminal emulator (Termux), so it is not a network issue.

Additionally, a separate machine running Linux Mint 19.2 an Emacs 25.2.2 loads arxiv.org without issue.

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
reply via email to

[Prev in Thread] Current Thread [Next in Thread]