2

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.

Moonwalker
  • 2,180
  • 1
  • 29
  • 48
  • If you cannot stop the server on the machine that works, can you start a similar server on the machine that doesn't? At least, that would give you a hint if you're looking in the right place. My suspicion, though, would be you are slightly misusing (or there's a bug in) a native library, possibly your database connection, and that bug is exposed by the different architecture. – Michael Lorton Feb 16 '12 at 23:56
  • My other machines are only x32 and everything works fine with them. The problem is my other machines are not for production, they are some kind of test/temp servers and I have to write code to be run on production server. – Moonwalker Feb 17 '12 at 04:23
  • I cannot imagine how this would have to do with Twisted. My guess: bad RAM. – Glyph Feb 18 '12 at 00:18
  • @Glyph -- This could be caused by a particular bit of bad hardware only if the OS is loading the Python interpreter exactly the same way every time; very unlikely. OP: what you have to do now is try to narrow the possibilities. First try to find *where* the crash is occurring. This means lots of print statements (yes, you're partying like it's 1979). It'll probably be in the `run` somewhere, because God hates programmers, and that means there's a flaw in the Python installation; re-install. With luck, though, it will be in the database call, and you can investigate further there. – Michael Lorton Feb 18 '12 at 02:03
  • Well, the problem resolved itself a few hours ago: server stopped to respond to the outside world and I had to reboot it. Now everything works fine. It's actually new server being bought a few days ago and may be there is a real problem with hardware. – Moonwalker Feb 18 '12 at 04:00
  • Not sure how to figure it out though. – Moonwalker Feb 18 '12 at 05:02
  • get traceback with [faulthandler](http://pypi.python.org/pypi/faulthandler/). – jfs Feb 18 '12 at 15:05

2 Answers2

4

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.

Dologan
  • 4,554
  • 2
  • 31
  • 33
2

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. :)

Jean-Paul Calderone
  • 47,755
  • 6
  • 94
  • 122
  • I've run memtester and found nothing. Error never occurred again after reboot of the server so I guess problem kind of solved. Thank you all for your responses. – Moonwalker Feb 18 '12 at 21:30