2015-08-14 2 views
1

У меня есть веб-сервер (CherryPy) работает с на Cubox (armhf платформа) и при запуске Вевера я получаю следующее сообщение об ошибке:time.gmtime() вызывает OverflowError на armhf платформе

[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 

Я не уверен, правильно ли я понял проблему, и я не уверен, может ли она быть исправлена ​​мной. Насколько я могу судить по Traceback, это вызвано CherryPy. Эта ошибка вызывает 500 Internal Server Error и не загружает страницу.

Как уже было сказано в комментариях, я вставил печать. Я не вижу ничего особенного. Это выход запуска сервера и один раз при попытке загрузить страницу:

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 впереди? На оконном компьютере time.gmtime(4593151133.439074) возвращает структуру, которая содержит год 2115.

На Cubox при запуске оболочки python и вводе time.gmtime(4593151133.439074) Я могу воспроизвести ошибку. Но я не знаю, откуда взялись эти ценности.

EDIT

Я нашел файл и строку в CherryPy, который возвращает меня плавающие числа, которые ведут к 2115. году это линия 949 - 951 в файле session.py:

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

Почему я получаю такой высокий тайм-аут, я не знаю.

+0

Правильно ли вы установили системное время? – muddyfish

+0

@muddyfish Я запускаю сервер на Debian, а вывод 'date' is' Fri Aug 14 09:54:41 CEST 2015'. Думаю, системное время верно? – ap0

+0

Это также может быть ошибка Python на вашей платформе. Можете ли вы поместить 'print (timeval)' в строку 177, чтобы узнать, какое значение вызывает переполнение? – saaj

ответ

1

Я нашел проблему. Сотрудник установил тайм-аут на очень высокое значение таймаута, которое не вызывало каких-либо проблем в Linux или Windows с архитектурой 32/64 бит, но на armhf.

Я был в состоянии решить эту проблему, установив тайм-аут до более низкого значения с помощью

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

Я предполагаю, что имею смысл открыть проблему в Pyton bugtracker, если * armhf * официально поддерживается платформой Python. Я не вижу ни ограничения, ни уведомления о количестве секунд до [time.gmtime] (https://docs.python.org/3/library/time.html#time.gmtime). – saaj

+1

@saaj: [* "Большинство функций, определенных в этом модуле, вызывают платформу платформы C с одинаковыми именами. Иногда бывает полезно ознакомиться с документацией на платформе, поскольку семантика этих функций зависит от платформы. * * (https://docs.python.org/3/library/time.html#module-time) Обратитесь к 'man 3 gmtime', чтобы узнать ограничения диапазона. Или [используйте модуль 'datetime', который предоставляет более переносимую семантику] (http://stackoverflow.com/a/32020010/4279) – jfs

1

Чтобы обойти ограничение диапазона для C gmtime() на armhf платформы, вы можете использовать явную формулу, чтобы получить время UTC от метки времени POSIX as the docs suggest:

>>> 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