【问题标题】:time.gmtime() causes OverflowError on armhf platformtime.gmtime() 导致 armhf 平台上的 OverflowError
【发布时间】:2015-11-07 09:44:55
【问题描述】:

我有一个在 Cubox(armhf 平台)上运行的网络服务器 (CherryPy),在启动 wever 时出现以下错误:

[14/Aug/2015:09:33:40] HTTP Traceback (most recent call last):
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 661, in respond
    self.hooks.run('before_request_body')
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 114, in run
    raise exc
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 104, in run
    hook()
  File "(...)/lib/python3.4/site-packages/cherrypy/_cprequest.py", line 63, in __call__
    return self.callback(**self.kwargs)
  File "(...)/lib/python3.4/site-packages/cherrypy/lib/sessions.py", line 901, in init
    httponly=httponly)
  File "(...)/lib/python3.4/site-packages/cherrypy/lib/sessions.py", line 951, in set_response_cookie
    cookie[name]['expires'] = httputil.HTTPDate(e)
  File "(...)/lib/python3.4/site-packages/cherrypy/_cpcompat.py", line 278, in HTTPDate
    return formatdate(timeval, usegmt=True)
  File "/usr/lib/python3.4/email/utils.py", line 177, in formatdate
    now = time.gmtime(timeval)
OverflowError: timestamp out of range for platform time_t

我不确定我是否正确理解了这个问题,也不确定我是否可以解决这个问题。据我所知,它是由 CherryPy 引起的。此错误会导致 500 Internal Server Error 并且不会加载页面。

按照 cmets 的要求,我插入了一个打印件。我看不出有什么特别的。这是启动服务器并尝试加载页面的输出:

1439551125.1483066
1439551132.639804
4593151132.6458025
1439551132.723468
1439551132.7210276
1439551132.7268708
1439551132.7359934
1439551132.741787
1439551132.7452564
4593151132.750907
4593151132.762612
4593151132.749376
4593151132.731232
4593151132.754474
4593151132.763546
1439551132.8183882
4593151132.828029
1439551132.8379567
4593151132.856025
1439551132.8734775
1439551132.8554301
1439551132.879614
4593151132.884698
4593151132.890394
1439551132.8971672
4593151132.902081
4593151132.908171
1439551132.931757
4593151132.944052
1439551132.9759347
1439551132.9714596
4593151132.987068
4593151132.985899
1439551132.9926524
1439551133.0088623
4593151133.013047
1439551133.0280995
4593151133.040709
4593151133.029601
1439551133.0500746
4593151133.057341
1439551133.0749385
4593151133.081711
1439551133.1032782
4593151133.115171
1439551133.1194305
1439551133.1354048
4593151133.143136
4593151133.151044
1439551133.1612003
4593151133.16934
1439551133.1827784
4593151133.19687
1439551133.201899
4593151133.209947
1439551133.271833
4593151133.277573
1439551133.3090906
4593151133.312978
1439551133.3408027
4593151133.344741
1439551133.3722978
4593151133.376283
1439551133.4031894
4593151133.407124
1439551133.434834
4593151133.439074

我不确定这些值中的哪一个会导致错误。我猜是前面有4的那个?在 Windows 机器上,time.gmtime(4593151133.439074) 返回一个包含 2115 年的结构。

在 Cubox 上启动 python shell 并输入 time.gmtime(4593151133.439074) 时,我可以重现该错误。但我不知道这些值是从哪里来的。

编辑

我在 CherryPy 中找到了文件和行,它返回了导致 2115 年的浮点数。它是文件 session.py 中的第 949 - 951 行:

if timeout:
    e = time.time() + (timeout * 60)
    cookie[name]['expires'] = httputil.HTTPDate(e)

我不知道为什么我的超时时间这么长。

【问题讨论】:

  • 您是否正确设置了系统时间?
  • @muddyfish 我在 Debian 上运行服务器,date 的输出是Fri Aug 14 09:54:41 CEST 2015。那我猜系统时间是对的?
  • 它也可能是您平台上的 Python 错误。你能把print(timeval)放在第177行看看是什么值导致溢出吗?
  • @saaj 我已经编辑了我的问题。
  • python -m trace --trace script.py

标签: python datetime cherrypy


【解决方案1】:

我找到了问题。一位同事将超时设置为一个非常高的超时值,这不会在具有 32/64 位架构的 Linux 或 Windows 上但在 armhf 上造成任何问题。

我可以通过将超时设置为较低的值来解决问题

cherrypy.request.config.update({'tools.sessions.timeout': 60}) 

【讨论】:

【解决方案2】:

要解决 armhf 平台上 C gmtime() 的范围限制,您可以使用显式公式从 POSIX 时间戳 as the docs suggest 获取 UTC 时间:

>>> from datetime import datetime, timedelta
>>> datetime(1970, 1, 1) + timedelta(seconds=4593151133.439074)
datetime.datetime(2115, 7, 21, 11, 18, 53, 439074)
>>> datetime.utcfromtimestamp(4593151133.439074) # calls gmtime() internally
datetime.datetime(2115, 7, 21, 11, 18, 53, 439073) # almost same result on non-"right" timezones

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2014-07-20
    • 2019-02-23
    • 1970-01-01
    • 2020-05-10
    • 2021-01-26
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多