On 6/15/06, Philip Jenvey <[EMAIL PROTECTED]> 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 and google for more info/examples. > > -- > Philip Jenvey
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 --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
