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 and google for more info/examples. -- Philip Jenvey --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss -~----------~----~----~----~------~----~------~--~---
