From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: "A.C." Newsgroups: gmane.emacs.bugs Subject: bug#37974: eww produces "error in process filter: Specified time is not representable" Date: Tue, 29 Oct 2019 08:05:57 -0400 Message-ID: <1FB46AE7-5E98-443D-950D-212F81FF5E77@gmail.com> References: <20191029003245.GA10341@arch-chirva.localdomain> <20191029045102.GA5852@D-69-91-141-110.dhcp4.washington.edu> <20191029102522.GA26999@D-69-91-141-110.dhcp4.washington.edu> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----6HTIRIKIA4ZC4XHF3GOZQ98N0XD24T" Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="225459"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: K-9 Mail for Android To: 37974@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Tue Oct 29 13:08:37 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1iPQId-000wV6-Gi for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2019 13:08:35 +0100 Original-Received: from localhost ([::1]:56120 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPQIc-0001Jn-6M for geb-bug-gnu-emacs@m.gmane.org; Tue, 29 Oct 2019 08:08:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43900) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPQHB-0008NX-1l for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 08:07:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPQH9-0002nI-56 for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 08:07:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:38171) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iPQH9-0002nE-28 for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 08:07:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1iPQH8-00076Z-7F for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 08:07:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: "A.C." Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 29 Oct 2019 12:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 37974 X-GNU-PR-Package: emacs X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.157235077727255 (code B ref -1); Tue, 29 Oct 2019 12:07:02 +0000 Original-Received: (at submit) by debbugs.gnu.org; 29 Oct 2019 12:06:17 +0000 Original-Received: from localhost ([127.0.0.1]:46991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPQGO-00075W-Tz for submit@debbugs.gnu.org; Tue, 29 Oct 2019 08:06:17 -0400 Original-Received: from lists.gnu.org ([209.51.188.17]:45054) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1iPQGK-00075M-5R for submit@debbugs.gnu.org; Tue, 29 Oct 2019 08:06:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:43668) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1iPQGI-00076i-0y for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 08:06:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1iPQGB-0002U9-KV for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 08:06:09 -0400 Original-Received: from mail-qt1-x82b.google.com ([2607:f8b0:4864:20::82b]:43108) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1iPQGB-0002Tz-EE for bug-gnu-emacs@gnu.org; Tue, 29 Oct 2019 08:06:03 -0400 Original-Received: by mail-qt1-x82b.google.com with SMTP id c26so1102328qtj.10 for ; Tue, 29 Oct 2019 05:06:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:user-agent:in-reply-to:references:mime-version :content-transfer-encoding:subject:to:from:message-id; bh=xRdNAAQrOJfj3xOXYpdkF3gxqxC6EgOYMDIZ7D31/rE=; b=mm1Aw7KLAfR/5FwYOEv8kIDYR8aqC4TTXTgYQnt1Ufq17fRxNfrRjNL6GVYg5MPZLm G1+CgX6M1rtQIHgCNJn4XclpA5DpXyGFbjlxeeo+eSzb43xqtw8HauxxvfVs/wScmOz6 FixQRuUP7NvxiziHovWp8JBISPmhGsrKUwKUiMzU/9E5rdFc0k4+He9zPyMB6HmptUjy TTmOJoy0WpD2dMu1HRTWVWkHdZTZg2aEC6PfwokXHNBIeY6v0ysSfyb9HoEDojgzIKD6 shAyyaj6coVGbZSbdUA3mMCf6/We9sjh0eJagnuDbrtQccmJC6jr7soTQ5IM/WBYSBmk eJ0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:from:message-id; bh=xRdNAAQrOJfj3xOXYpdkF3gxqxC6EgOYMDIZ7D31/rE=; b=DqszBMLNThf0uUHd9q1kB/Z3yoXHbkDu/TwrTY2sPT3ySWMrWMNoMiaphZEydgPnDJ nocJoA2gzSnPZZ9/sQcm/4G9/jcjUFJjGOHVF7TTdgmsGA992ZV9rYQNeDYAOqX8fqWQ 11LgrKn6aQ6NnpqHonIOFgSAMvD3TfsuwVR57izAqqZ/RCXkXyyDbAdb8QjJzIsu+4Se 5JnTnKvBEULOHvmIT9nKiF5UPgvolem7YcViPx8VcvminaGdY1HpmU1F4ZFtPr98U6Qy 0wntuQBWFaAOKeYJx/RSxMz3EQbQEFoa2/GSUAvzllahlM8dAmD1jkRshNDnqNZeDmT2 K+AQ== X-Gm-Message-State: APjAAAVLIHElHh4X1QZAFCq1XDq89unX+DKE1LcygBHyrRX+F+lcXkpf itbtFWz7moJh2hvVvd5tBRn+lMuW X-Google-Smtp-Source: APXvYqz4IC3TryRTR6q56a1hdOljN/iCulCepgXcbpoY//IklUG1JcDrgUK03d+F2omOSzYxlxM5zQ== X-Received: by 2002:ad4:4d0f:: with SMTP id l15mr15579824qvl.78.1572350762570; Tue, 29 Oct 2019 05:06:02 -0700 (PDT) Original-Received: from [192.168.1.171] (pool-68-133-6-220.bflony.fios.verizon.net. [68.133.6.220]) by smtp.gmail.com with ESMTPSA id l93sm8252609qtd.86.2019.10.29.05.06.01 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Oct 2019 05:06:01 -0700 (PDT) In-Reply-To: <20191029102522.GA26999@D-69-91-141-110.dhcp4.washington.edu> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:170365 Archived-At: ------6HTIRIKIA4ZC4XHF3GOZQ98N0XD24T Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable This must be a word-size issue: on *all* systems where=20 M-x eww RET arxiv=2Eorg RET loads all right the largest n such that *scratch* evaluation of=20 (format-time-string "%a %b %d %H:%M:%S %Y GMT" (list n 0 0 0))=20 produces a valid date is=20 n=3D1034058169428 (exact same n on two x86_64 machines and an aarch64 Android phone)=2E Also= , all of these systems return=20 $ getconf WORD_BIT 32 $ getconf LONG_BIT 64 On the other hand, the Debian i686 system that doesn't load arxiv=2Eorg ha= s a largest valid n of n=3D32767=3D2**15-1 and returns=20 $ getconf WORD_BIT 32 $ getconf LONG_BIT 32 That's why it chokes on arxiv=2Eorg: 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=2E3 from 26=2E1 would address this= in any way=2E =20 On October 29, 2019 6:25:22 AM EDT, Stuart Little = wrote: >I believe I've isolated this as far as I can: the systems running Emacs >26=2E1 and 26=2E3 respectively have identical code for the function >'url-cookie-handle-set-cookie', so that on its own is not the problem=2E >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"=2E 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"=2E =20 > >On Tue, Oct 29, 2019 at 12:51:02AM -0400, Stuart Little wrote: >> Apologies for the uninformative message below=2E I know slightly more >now=2E >>=20 >> Setting debug-on-error and running >>=20 >> M-x eww RET arxiv=2Eorg RET >>=20 >> again produces the following trace: >>=20 >> --- cut here --- >>=20 >> Debugger entered--Lisp error: (error "Specified time is not >representable") =20 > =20 >> format-time-string("%a %b %d %H:%M:%S %Y GMT" (38427 52290 103040 >624000) t) >> =20 >url-cookie-handle-set-cookie("browser=3D68=2E133=2E6=2E220=2E157232416097= 9722; >path=3D/; max-age=3D946080000; domain=3D=2Earxiv=2Eorg") >> url-http-handle-cookies() >> url-http-parse-headers() >> url-http-chunked-encoding-after-change-function(7029 7034 5) >> url-http-generic-filter(#> "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) >>=20 >> --- done --- >>=20 >> This told me the problem was with the url-cookie-handle-set-cookie >function; specifically, with the format-time-string directive therein=2E >I tried to fiddle with it to confirm=2E Indeed, replacing the relevant >if-then-else clause >>=20 >> --- cut --- >>=20 >> (if (and max-age (string-match "\\`-?[0-9]+\\'" max-age)) =20 > =20 >> (setq expires (format-time-string "%a %b %d %H:%M:%S %Y GMT" =20 > =20 >> (time-add nil (read >max-age)) =20 > =20 >> t)) =20 > =20 >> (setq expires (cdr-safe (assoc-string "expires" args t)))) >>=20 >> --- done --- >>=20 >> therein with just the else branch >>=20 >> (setq expires (cdr-safe (assoc-string "expires" args t))) >>=20 >> resolves the issue=2E arxiv=2Eorg loads fine with the redefined >url-cookie-handle-set-cookie function=2E=20 >>=20 >> On Mon, Oct 28, 2019 at 08:32:45PM -0400, Stuart Little wrote: >> > I am on a Debian 10=2E1 machine i686=2E The current Emacs version in >this Debian repo is 26=2E1=2E >> >=20 >> > My issue is that >> >=20 >> > M-x eww RET arxiv=2Eorg RET >> >=20 >> > fails to load the page and produces the error >> >=20 >> > error in process filter: Specified time is not representable >> >=20 >> > in the minibuffer=2E Other websites load fine (e=2Eg=2E nytimes=2Ecom= , >theguardian=2Ecomn, google=2Ecom)=2E Others, on the other hand, simply >silently time out: duckduckgo=2Ecom and thenation=2Ecom behave this way >(the minibuffer reports 'contacting host' but the page never loads)=2E >> >=20 >> > Everything loads fine on an Arch Linux x86_64 machine running Emacs >26=2E3 as well as an Android 9 phone running an ARM version of Emacs 26= =2E3 >in a terminal emulator (Termux), so it is not a network issue=2E >> >=20 >> > Additionally, a separate machine running Linux Mint 19=2E2 an Emacs >25=2E2=2E2 loads arxiv=2Eorg without issue=2E --=20 Sent from my Android device with K-9 Mail=2E Please excuse my brevity=2E ------6HTIRIKIA4ZC4XHF3GOZQ98N0XD24T Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable This must be a word-size issue: on *all* systems w= here

M-x eww RET arxiv=2Eorg 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= =3D1034058169428

(exact same n on two x86_64 machines and an aarch64= Android phone)=2E 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=2Eorg has a largest valid n of

= n=3D32767=3D2**15-1

and returns

$ getconf WORD_BIT
32
= $ getconf LONG_BIT
32

That's why it chokes on arxiv=2Eorg: loadin= g 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 kn= ow that upgrading to Emacs 26=2E3 from 26=2E1 would address this in any way= =2E



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

On the former, evaluating

(f=
ormat-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"=2E On t=
he other hand, evaluating the exact same function in the *scratch* buffer o=
n the Debian system produces the error "Specified time is not representable=
"=2E  

On Tue, Oct 29, 2019 at 12:51:02AM -0400, Stuart Little wrote=
:
Apologies for the uni=
nformative message below=2E I know slightly more now=2E

Setting debu=
g-on-error and running

M-x eww RET arxiv=2Eorg RET

again prod=
uces the following trace:

--- cut here ---

Debugger entered--=
Lisp error: (error "Specified time is not representable")                  =
                                                                  
  for=
mat-time-string("%a %b %d %H:%M:%S %Y GMT" (38427 52290 103040 624000) t)  url-cookie-handle-set-cookie("browser=3D68=2E133=2E6=2E220=2E1572324160=
979722; path=3D/; max-age=3D946080000; domain=3D=2Earxiv=2Eorg")
  url-h=
ttp-handle-cookies()
  url-http-parse-headers()
  url-http-chunked-en=
coding-after-change-function(7029 7034 5)
  url-http-generic-filter(#<=
;process arxiv=2Eorg<1>> "0\015\n\015\n")
  read-event(nil t 2)=

  sit-for(2)
  execute-extended-command(nil "eww" "eww")
  funcal=
l-interactively(execute-extended-command nil "eww" "eww")
  call-interac=
tively(execute-extended-command nil nil)
  command-execute(execute-exten=
ded-command)

--- done ---

This told me the problem was with t=
he url-cookie-handle-set-cookie function; specifically, with the format-tim=
e-string directive therein=2E I tried to fiddle with it to confirm=2E Indee=
d, 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 (re=
ad max-age))                                                               =
                         
                                         t))  =
                                                                           =
                                     
      (setq expires (cdr-safe (ass=
oc-string "expires" args t))))

--- done ---

therein with just=
 the else branch

(setq expires (cdr-safe (assoc-string "expires" arg=
s t)))

resolves the issue=2E arxiv=2Eorg loads fine with the redefin=
ed url-cookie-handle-set-cookie function=2E 

On Mon, Oct 28, 2019 at=
 08:32:45PM -0400, Stuart Little wrote:
I am on a Debian 10=2E1 machine i686=2E The current Emacs =
version in this Debian repo is 26=2E1=2E

My issue is that

M-x=
 eww RET arxiv=2Eorg RET

fails to load the page and produces the err=
or

error in process filter: Specified time is not representable
<=
br>in the minibuffer=2E Other websites load fine (e=2Eg=2E nytimes=2Ecom, t=
heguardian=2Ecomn, google=2Ecom)=2E Others, on the other hand, simply silen=
tly time out: duckduckgo=2Ecom and thenation=2Ecom behave this way (the min=
ibuffer reports 'contacting host' but the page never loads)=2E

Every=
thing loads fine on an Arch Linux x86_64 machine running Emacs 26=2E3 as we=
ll as an Android 9 phone running an ARM version of Emacs 26=2E3 in a termin=
al emulator (Termux), so it is not a network issue=2E

Additionally, =
a separate machine running Linux Mint 19=2E2 an Emacs 25=2E2=2E2 loads arxi=
v=2Eorg without issue=2E

--
Sent from my Android device with K-9 Mail=2E Please excuse m= y brevity=2E ------6HTIRIKIA4ZC4XHF3GOZQ98N0XD24T--