web.twisted 的神秘“总线错误”（代码在一台服务器上运行，而在另一台服务器上运行）答案

【问题标题】：Mysterious "Bus error" with web.twisted (code works on one server and does not on the another)web.twisted 的神秘“总线错误”（代码在一台服务器上运行，而在另一台服务器上运行）
【发布时间】：2012-03-08 10:01:10
【问题描述】：

我只是想一一展示一些数据库的元素：

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 Fri Jan 27 19:24:01 UTC 2012 i686 i686 i386 GNU/Linux）一切正常。在另一个系统上（Linux localhost 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux）

我得到了以下信息：

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

我认为两台服务器之间的唯一区别是（除了 x32 / x64 形式）第二台服务器上有类似的扭曲进程。这个过程做一些重要的事情并且真的不想终止或以任何其他方式干扰它只是为了检查我的测试代码是否有效。

【问题讨论】：

如果你不能在正常工作的机器上停止服务器，你能在不工作的机器上启动一个类似的服务器吗？至少，如果你找对了地方，那会给你一个提示。不过，我的怀疑是您稍微滥用（或存在错误）本机库，可能是您的数据库连接，并且该错误由不同的架构暴露。
我的其他机器只有 x32，一切正常。问题是我的其他机器不是用于生产的，它们是某种测试/临时服务器，我必须编写代码才能在生产服务器上运行。
我无法想象这与 Twisted 有什么关系。我的猜测：内存不好。
@Glyph -- 仅当操作系统每次都以完全相同的方式加载 Python 解释器时，这可能是由特定的坏硬件引起的；不太可能。 OP：你现在要做的是尽量缩小可能性。首先尝试查找发生崩溃的位置。这意味着大量的印刷声明（是的，您正在像 1979 年一样参加派对）。它可能在run 某处，因为上帝讨厌程序员，这意味着 Python 安装存在缺陷；重新安装。不过，如果运气好的话，它将在数据库调用中，您可以在那里进一步调查。
好吧，问题在几个小时前自行解决了：服务器停止响应外部世界，我不得不重新启动它。现在一切正常。这实际上是几天前购买的新服务器，可能硬件确实存在问题。

标签： python twisted twisted.web bus-error

【解决方案1】：

试试memtest86+之类的工具来判断机器中的系统内存是否坏了。看起来很可能是这样，并且正确存储或检索数据的随机失败导致了您的问题。

更一般地说，当您遇到此类问题时，您应该获取软件的调试版本（在本例中为 Python）并启用核心转储（请参阅 ulimit(1)）。当您在此配置中重现崩溃时，您可以使用 gdb 检查核心转储以了解触发崩溃的代码。在内存模块损坏的情况下，崩溃通常发生在某个随机的、荒谬的地方，代码看起来都是正确的（但无论如何都会失败，因为违反了基本假设，即数据一旦计算并存储在内存中，就会保持不变，直到更改）。

但是，您可能会发现崩溃总是发生在代码的同一部分，您甚至可以发现错误。然后，修复错误并继续前进。 :)

【讨论】：

我运行了 memtester 并没有发现任何东西。重新启动服务器后再也没有发生错误，所以我想问题已经解决了。谢谢大家的回复。

【解决方案2】：

在我最近的案例中，这与文件系统中启用（并超过）用户配额有关。我想当分区上没有剩余空间时也可能发生这种情况。

【讨论】：