Загадочная «ошибка шины» с web.twisted (код работает на одном сервере, а на другом нет) - PullRequest
2 голосов
/ 17 февраля 2012

Я просто пытаюсь показать элементы какой-то базы данных, одну за другой:

from twisted.web import server, resource
from twisted.internet import reactor
from pymongo import Connection
import time
import pprint


class ZenResource(resource.Resource):
    isLeaf = True

    connection = Connection('...', 27017)
    db = connection.data
    db.authenticate("...","...")
    iter = db.index.find()

    def render_GET(self, request):
        item = self.iter.next()
        # ... simple processing, skipped some simple strings manipulations:
        htmlLines = []
        for textLine in pprint.pformat(item).splitlines():
            htmlLines.append('<br/>%s' % textLine) 
        htmlText = '\n'.join(htmlLines)
        request.setHeader("Content-type", 'text/html; charset=UTF-8')
        return htmlText.encode("utf8")

reactor.listenTCP(48088, server.Site(ZenResource()))
reactor.run()

В одной системе (Linux hh 3.0.0-16-generic-pae # 28-Ubuntu SMP пт 27 января 19:24:01 UTC 2012 i686 i686 i386 GNU / Linux) все работает отлично. В другой системе (Linux localhost 2.6.38-8-сервер # 42-Ubuntu SMP Пн 11 апреля 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU / Linux)

Я получил следующее:

root@localhost:~# python zen.py  
Bus error

Единственное различие между двумя серверами, о котором я думаю (кроме формы x32 / x64), заключается в том, что на втором сервере существует похожий витой процесс. Этот процесс делает что-то важное и действительно не хочет завершаться или каким-либо другим образом мешать ему, просто чтобы проверить, работает ли мой тестовый код.

Ответы [ 2 ]

3 голосов
/ 12 февраля 2016

В моем недавнем случае это было связано с включением (и превышением) пользовательских квот в файловой системе. Я полагаю, это также может произойти, если на разделе не осталось свободного места.

2 голосов
/ 18 февраля 2012

Попробуйте инструмент, подобный memtest86 + , чтобы определить, плохая ли системная память в машине. Вероятно, это так, и случайные сбои в хранении или извлечении данных приводят к вашей проблеме.

В более общем случае, когда у вас возникла такая проблема, вы должны получить отладочную сборку программного обеспечения (в данном случае Python) и включить дамп ядра (см. Ulimit (1)). Когда вы воспроизводите сбой в этой конфигурации, вы можете использовать gdb, чтобы проверить дамп ядра, чтобы узнать, какой код вызывает сбой. В случае плохих модулей памяти сбой, как правило, происходит в каком-то случайном, бессмысленном месте, где весь код выглядит корректным (но в любом случае происходит сбой из-за нарушений базового предположения о том, что данные, однажды вычисленные и сохраненные в памяти, остаются неизменными до тех пор, пока измененная).

Однако вы можете обнаружить, что сбой всегда происходит в одной и той же части кода, и вы даже сможете обнаружить ошибку. Затем исправьте ошибку и продолжайте. :)

...