Mysterious “Bus error” with web.twisted (code works on one server and does not on the another)

Question

I'm just trying to show elements of some database, one by one:

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

On the one system (Linux hh 3.0.0-16-generic-pae #28-Ubuntu SMP Fri Jan 27 19:24:01 UTC 2012 i686 i686 i386 GNU/Linux) everything works fine. On the other system (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)

I got the following:

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

The only difference between two servers that I think of is (aside form x32 / x64) is that there is a similar twisted process on the second server. This process doing something important and a really do not want to terminate or in any other way interfere with it just to check whether my test code works.

Answer 1

Try a tool like memtest86+ to determine whether the system memory in the machine is bad. It seems likely that it is, and that random failures to store or retrieve data correctly are leading to your issue.

More generally, when you have a problem like this, you should get a debug build of the software (in this case, Python) and enable core dumps (see ulimit(1)). When you reproduce the crash in this configuration, you can use gdb to examine the core dump to learn what code is triggering the crash. In the case of bad memory modules, the crash will generally be in some random, nonsensical place where the code all appears correct (but fails anyway due to violations in the underlying assumption that data, once computed and stored in memory, remains the same until changed).

However, you might discover that the crash always occurs in the same part of the code, and you may even be able to spot the bug. Then, fix the bug and move on. :)

Answer 2

In my recent case, this was related to user quotas being enabled (and exceeded) in the filesystem. I imagine it might also occur when there is no free space left on the partition.