emacs eww: error in process filter when loading pages

[stuart-little]

I'm on an armv7l phone running Android 5.1 and emacs 26.1 (latest as I type this).

I've only now noticed that the built-in eww browser is misbehaving. It loads some pages fine, such as google.com or duckduckgo.com. However, every time I pass it arxiv.org, for instance, I get

error in process filter: Specified time is not representable

Immediately after receiving such an error some websites that normally load fine (i.e. nytimes.com and theguardian.com) then start failing to load with

<website>/80 No address associated with hostname

After a few minutes the newly-disabled webpages start loading again, but arxiv.org always fails with the 'time-is-not-representable' error.

Edit

I downgraded to version 25.3-2 of the emacs package from the xeffyr repo. The older version does not exhibit the issue; all web pages I've tried load up all right.

Additionally, those pages that do load in both instances of the package seem to do so faster in 25.3-2 than in 26.1.

[stuart-little]

I now believe this can be closed. I'll try to document what I think is going on. I'm exchanging some mail with the folks over on the emacs bug-reporting list at bug-gnu-emacs@gnu.org.

In short, I think this is a version of the year-2038 problem affecting 32-bit systems (which the device I reported this on was).

---

Starting with version 26.1, calling M-x eww RET arxiv.org RET in emacs will attempt to call the function

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

(that's what the emacs debugger displays). On 64-bit systems that would produce the date

Thu Oct 21 05:59:23 2049 GMT

which is when one of the arxiv.org cookies is supposed to expire. The date is produced from that quadruple of integers as explained in the time-of-day emacs documentation (top of page): for a quadruple

(high,low,micro,pico)

the corresponding time is

high*2**16 + low + micro*10**(-6) + pico*10**(-12)

seconds from the Unix epoch. The problem is that in the present case that's more than

2147483647 = 2**31-1

seconds, so 32-bit systems will apparently choke.

As additional evidence, the problem is recurring on a 32-bit Debian laptop running emacs 26.1 but on none of my 64-bit systems, including x86_64 laptops / desktops and an aarch64 Android 9 phone.

EDIT

The emacs bug discussion is at

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=37974#5