Problems with python and threads under Freebsd

S

snacktime

I posted this to freebsd-questions, but though I would put it here
also in case anyone has any ideas.

I am consistantly getting seg faults and bus errors when running a
multi threaded python application under 5.3-release-p2. Python was
built from the port(python 2.4) with threading enabled. Rebuilding
with the huge stack size option enabled didn't make a difference. The
application uses twisted (www.twistedmatrix.com) and it runs fine
until I put it under a bit of a load and have 20-30 simultaneous
threads running. Then it core dumps. Following is the backtrace from
the core file. The backtrace is always the same.

#0 0x2823cdbb in pthread_testcancel () from /usr/lib/libpthread.so.1
#1 0x28234b06 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1
#2 0x00000000 in ?? ()
 
S

Stefan Schwarzer

snacktime said:
I am consistantly getting seg faults and bus errors when running a
multi threaded python application under 5.3-release-p2. Python was
built from the port(python 2.4) with threading enabled.

I had similar problems some time ago. The solution/workaround was to remove
the threading library-related mappings from /etc/libmap.conf . Perhaps you
need to do that or the opposite, i. e. add a mapping.

What do you get if you run the threading tests
in /usr/local/lib/python2.4/test/test_thread*.py ? In my case,
test_threaded_import.py failed before the libmap.conf change.

If the libmap.conf change doesn't help, you could try to rebuild the base
system and kernel and after that the Python port. Also, reading the
UPDATING files for the base system and the ports tree may give you a hint.

Stefan
 
S

snacktime

This is a followup with some more information. The program is written
in twisted and I posted this to twisted-python also. The freebsd list
wants a more detailed backtrace, which even with python compiled with
OPT -g and --with-pydebug isn't happening for some reason.

The script below calls a blocking method using deferToThread. When I
have 5 or so clients all hitting it at the same time I get a segfault
or bus error within minutes.
I recompiled python with --with-pydebug and set OPT to -g, but it
didn't give me any more information in the backtrace which is also
below. Then I ran gdb on the server process and something funny
happened. I didn't get a segfault, but the server started catching
exceptions and printing them to the screen. As soon as I detached gdb
the exceptions stop but it dumps core a minute later (or less). The
exception is pasted below also.

Python was compiled with pthreads, which is the freebsd kse threads as
far as I know. Freebsd version is 5.3-release-p2.



Server code:
-----------------------------------------------------------
from twisted.internet.protocol import Protocol, Factory
from twisted.internet import defer, reactor
from twisted.python import threadable
from twisted.internet import threads
threadable.init(1)
from otransact.otdirect import process
from twisted.python import log

class GetData:

# this calls my blocking method. THe method blocks when doing
database calls with psycopg and when using urllib2 to do an https
POST. Other than that everything is non blocking. psycopg is
supposed to be thread safe, and I would assume urllib2 is also.

def Do(self,data):
response = process(data)
return response

### Protocol Implementation

# This is just about the simplest possible protocol
class Echo(Protocol):
def dataReceived(self, data):
"""As soon as any data is received, write it back."""
reactor.callLater(0, self.Start,data)

def PrintData(self,data):
self.transport.write("%s\r\n" % data)
self.transport.loseConnection()
#reactor.stop()

def Start(self,data):
c = GetData()
d = threads.deferToThread(c.Do,data)
d.addCallback(self.PrintData)
d.addErrback(log.err)

def main():
f = Factory()
f.protocol = Echo
reactor.listenTCP(8000, f)
reactor.run()

if __name__ == '__main__':
main()

Exception raised by server when gdb was running.
-----------------------------------------------------------------------

File "otssl.py", line 42, in ?
reactor.run()
File "/usr/local/lib/python2.4/site-packages/twisted/internet/default.py",
line 126, in run
self.mainLoop()
File "/usr/local/lib/python2.4/site-packages/twisted/internet/default.py",
line 134, in mainLoop
self.runUntilCurrent()
--- <exception caught here> ---
File "/usr/local/lib/python2.4/site-packages/twisted/internet/base.py",
line 423, in runUntilCurrent
call.func(*call.args, **call.kw)
File "/usr/home/otransact/ssl/ots.py", line 72, in Start
d = threads.deferToThread(c.Do,data)
File "/usr/local/lib/python2.4/site-packages/twisted/internet/threads.py",
line 48, in deferToThread
reactor.callInThread(_putResultInDeferred, d, f, args, kwargs)
File "/usr/local/lib/python2.4/site-packages/twisted/internet/base.py",
line 453, in callInThread
self.threadpool.callInThread(_callable, *args, **kwargs)
File "/usr/local/lib/python2.4/site-packages/twisted/python/threadpool.py",
line 130, in callInThread
self.q.put(o)
File "/usr/local/lib/python2.4/Queue.py", line 91, in put
self.not_full.release()
thread.error: release unlocked lock

Backtrace:
 
S

snacktime

After debugging this some more I narrowed it down to an encryption
function in pycrypto that is triggering the segfault. I posted a bug
report. Don't really know enough about threading to know whether it's
a python bug or a pycrypto bug, but I'll let someone else sort that
out now..

Chris
 
A

Andrew MacIntyre

snacktime said:
After debugging this some more I narrowed it down to an encryption
function in pycrypto that is triggering the segfault. I posted a bug
report. Don't really know enough about threading to know whether it's
a python bug or a pycrypto bug, but I'll let someone else sort that
out now..

If you get bus errors, there's a possibility that you are running out of
stack.

AFAIR, the default thread stack size for Posix builds is dependant on
the threading implementation. This can be overridden when building Python.

With each gcc version since 2.9, the size of stack frames for generated
calls has increased. If lowering the optimisation to -O or -Os when
building Python improves the situation, I'd suggest pursuing this
possibility further.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top