All I can suggest at this point are:
1. Disable the background email thread and see if the problem still occurs.
2. Force application to run in main interpreter by setting:
WSGIApplicationGroup %{GLOBAL}
This will eliminate possibility that problems are caused by a third
party C
Today I was not able to start my application as I got segmentation
faults constantly.
I've attached gdb and that is the result:
(gdb) cont
Continuing.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1212216416 (LWP 29850)]
PyErr_Occurred () at Python/errors.c:80
80
Now, again, my application is working with the same setup as before
(without GLOBAL). I don't know why this started without segfault now.
Nothing has changed.
I have to mention that the issue that caused I was not able to start
my application today morning was
because my memory was over the limit
On 30 Wrz, 14:41, Graham Dumpleton [EMAIL PROTECTED]
wrote:
What do you get if you run:
ulimit -a
Maybe they have some sort of hard memory limits in place and you are
hitting that.
Output of ulimit -a is:
---
core file size
I've managed to get segmentation fault (I was just clicking around my
application, I forced few reloads of mod_wsgi by changing wsgi script,
etc.), and I was able to reproduce this few times.
Again, I've connected to it with gdb but this time I've issued command
'share' before 'bt'. Thanks to
Currently I use psycopg2 from the svn - version dated at January 2008.
I've just looked at initd.org's svn and I see there is psycopg2-2.0.8
and in change log from march I found:
2008-03-07 James Henstridge [EMAIL PROTECTED]
* psycopg/pqpath.c (_pq_fetch_tuples): Don't call Python
2.0.8 definitely fixed some segfaults on my end.
So far, since September 30 I have not seen any segmentation faults.
Seems that upgrade to 2.0.8 and using %{GLOBAL} solved the problem.
Graham, thank you for the support! :)
--
Maciej Wisniowski
