unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "A.C." <achirvasub@gmail.com>
To: 37974@debbugs.gnu.org
Subject: bug#37974: eww produces "error in process filter: Specified time is not representable"
Date: Tue, 29 Oct 2019 08:05:57 -0400	[thread overview]
Message-ID: <1FB46AE7-5E98-443D-950D-212F81FF5E77@gmail.com> (raw)
In-Reply-To: <20191029102522.GA26999@D-69-91-141-110.dhcp4.washington.edu>

[-- Attachment #1: Type: text/plain, Size: 5043 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 5554 bytes --]

  reply	other threads:[~2019-10-29 12:05 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-29  0:32 bug#37974: eww produces "error in process filter: Specified time is not representable" Stuart Little
2019-10-29  4:51 ` Stuart Little
2019-10-29 10:25   ` Stuart Little
2019-10-29 12:05     ` A.C. [this message]
2019-10-29 12:47       ` Lars Ingebrigtsen
2019-10-29 14:06         ` A.C.
2019-10-29 14:41           ` A.C.
2019-10-29 21:52           ` Lars Ingebrigtsen
2019-10-29 22:23             ` A.C.
2019-10-30 10:19               ` Colin Baxter
2019-10-30 11:01                 ` Lars Ingebrigtsen
2019-10-31 18:50                   ` A.C.
2019-11-01 13:46                     ` Lars Ingebrigtsen
2019-11-01  8:05 ` Paul Eggert
2019-11-01 23:22   ` Paul Eggert
2019-11-02  7:34     ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1FB46AE7-5E98-443D-950D-212F81FF5E77@gmail.com \
    --to=achirvasub@gmail.com \
    --cc=37974@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).