Django|django crash problem - Size does matter — tomster.org
Size does matter — tomster.org
Size does matter
From the obscure-obscenity-Department
Today, the Zope instance hosting this site experienced frequent crashes (as in "every couple of minutes) in the form of coredumps of the zope process. Stumped, bewildered, frustrated and near tears I did what I always do in such cases: pour my little heart out on #plone
;-)
Sure enough, help was at hand. And today's tip of the hat goes to... drumroll... lurker, who alerted me to the fact, that python needs explicit 'huge stack' suppport on FreeBSD. A bit of googling supported this view and so I reinstalled python from the ports, but first ran make config
and then enabled HUGE_STACK_SIZE
:
After that I ran a few stresstests with ab
and the instance easily withheld several thousand requests for the front page. Why this option isn't enabled by default is beyond me. So keep that in mind, kids, when you install python on your BSD boxen: size does matter ;-) (As if the term 'huge stack size' wasn't already obscene enough without such a foot-in-mouth reference...)
- cc set to karsten@rohrbach.de.
Wyatt Baldwin wrote:
On 6/15/06, Philip Jenvey <pjen...@groovie.org> wrote:
On Jun 15, 2006, at 6:56 PM, uuellbee wrote:
One known cause of core dumps on FreeBSD is when a python app needs a large stack size (this can be avoided by enabling the python port's HUGE_STACK_SIZE option), but since you're loading a simple app this can't be the problem.
I found some info on this and one suggestion was to #define THREAD_STACK_SIZE in thread_pthread.h. [See http://www.pythomnic.org/step_by_step.html.] I tried this instead of setting HUGE_STACK_SIZE because I'm compiling Python from source.
Here is the line I added:
#define THREAD_STACK_SIZE (0x100000)
Now when I visit the test site, it just keeps Loading... apparently forever. (It's been going in a another tab for a while now).
You might try switching the threading library via libmap.conf incase there's something strange related to threads.
I can't find libmap.conf on my system.
I tried compiling without threads, but something complained about not finding threads when I started the server. I also tried using the --with-pth option (GNU pth threading libraries), but that didn't change anything.
Otherwise to get some kind on information on why the core dump occurred you'll need to recompile python with debugging symbols. You can do this by putting the following line in /etc/make.conf prior to building the port:
CFLAGS=-g
Then you can run 'gdb python.core' and issue the 'bt' command to gdb to see a backtrace.
I'll recompile with the THREAD_STACK_SIZE hack removed and try this......
Here's what I get from running 'gdb ~/bin/python python.core': [Copyright, etc] This GDB was configured as "i386-marcel-freebsd"... Core was generated by `python'. Program terminated with signal 10, Bus error. [Bunch of lines of reading/loading symbols] #0 0x2825a31b in pthread_testcancel () from /usr/lib/libpthread.so.1
Here is the output of bt: #0 0x2825a31b in pthread_testcancel () from /usr/lib/libpthread.so.1 #1 0x28252902 in pthread_mutexattr_init () from /usr/lib/libpthread.so.1 #2 0x00000000 in ?? ()
This sounds pretty similar to this issue:
http://mail.python.org/pipermail/python-list/2005-April/276728.html
What's strange is he wasn't able to immediately reproduce the core dump while running python through GDB (mentioned here: http:// mail.python.org/pipermail/python-list/2005-February/265137.html ). You might want to also try what he did -- running python through gdb with the symbols enabled. Enabling the debugging symbols will hopefully provide a more thorough back trace and possibly explain why the larger thread stack size changed the behavior (I suspect there's a bigger problem that blows out the stack and the larger one simply postpones the problem).
Before doing that I would play with libmap.conf. There isn't an /etc/ defaults/libmap.conf, but there should be a man page for it on your system (libmap.conf(5)). You're currently using the libpthread threading library: what you want is to switch to the libthr library via libmap.conf (and hope the problem doesn't occur there).
I am currently doing this on a 7.0-CURRENT machine, and my libmap.conf looks like this:
libpthread.so.2 libthr.so.2 libpthread.so libthr.so
The version numbers are going to be different for FreeBSD 5.4. Check the man page aHUGE_STACK_SIZEnd google for more info/examples.
I'll take a deeper look into libmap. One thing that might be interesting is I installed Myghty by itself and had no problems, which would perhaps imply that the problem is somewhere in Paste (not that I really know what I'm talking about).
~wyatt
I never got around to messing around with gdb or libmap. I just set HUGE_STACK_SIZE in the FreeBSD Python port and everything works fine.
~wyatt
Could this be a stack size problem?
On FreeBSD, the default stack size is configured smaller than in most other distributions. This already bites on a regular basis with Zope installations. (e.g. things like http://tomster.org/blog/archive/2006/09/27/size-does-matter)
From a current FreeBSD port /usr/ports/lang/python24/Makefile: