As you have probably seen on #django. 00:51 karan Warning: GeoDjango uses the GEOS and GDAL geospatial libraries which are not thread safe at this time. Thus, it is highly recommended not to use threading when deploying – in other words, use a prefork version of Apache or the prefork method when using FastCGI through another web server.
I knew it was either threading or the main interpreter that was problem. My memory is getting really bad. ;-) All I can suggest if you can is to delegate specific URLs that rely on accessing GeoDjango to a daemon process of their own which is single threaded. WSGIDaemonProcess www.ibegin.com display-name=ibegin processes=3 threads=10 ... WSGIDaemonProcess www.ibegin.com:geodjango displayname=ibegin:geodjango processes=2 threads=1 WSGIScriptAlias / /home/ibegin/iplatform/handler.wsgi WSGIProcessGroup www.ibegin.com <Location /url/which/uses/geodjango> WSGIProcessGroup www.ibegin.com:geodjango </Location> Graham 2009/7/9 David Cramer <[email protected]>: > > After attempting to debug it with GDB/PDB I finally gave up. I failed > to find ANYTHING at all, and decided to run an svn up on Django. Bugs > gone, at least for now ;) > > On Jul 8, 8:23 pm, Graham Dumpleton <[email protected]> > wrote: >> 2009/7/9 David Cramer <[email protected]>: >> >> > I can't confirm if this has solved the GeoDjango issue but I can say that >> > the other issue is still present. Here's what I get (on any attempt, and >> > any >> > case) in the error log: >> >> > [Wed Jul 08 21:07:16 2009] [error] [client 207.97.208.143] Premature end of >> > script headers: handler.wsgi >> > [Wed Jul 08 21:07:16 2009] [error] [client 98.23.144.55] Premature end of >> > script headers: handler.wsgi >> > [Wed Jul 08 21:07:17 2009] [notice] child pid 21091 exit signal >> > Segmentation >> > fault (11) >> >> Going backwards a bit and explain this, not just to confirm your >> understanding, but so anyone else who sees this on the list in the >> future understands. >> >> The error message 'Premature end of script headers' would normally >> only ever happen when the mod_wsgi daemon process handling the request >> crashes. The error message is actually being generated from the Apache >> server child process which is proxying the request to the mod_wsgi >> daemon process. The 'Segmentation fault' message is then from memory >> generated by the Apache parent process when it detects that a child >> process it is managing has crashed. If core files are being produced, >> and because of how Apache parent detects child processes that have >> vanished, this message may not a small amount of time to appear in >> logs. >> >> > This is happening due to a MySQL warning (which I believe is called in >> > __del__) so it pipes to stderr instead of a normal exception. >> >> Not that it matters, mod_wsgi will replace sys.stderr in Python >> interpreter context such that stuff goes to Apache error log through >> normal Apache logging APIs, such that date time stamps etc are added. >> If MySQL is accessing C level stderr directly, it still goes to the >> Apache error log, however, because of how Apache redirects stderr, it >> is buffered and so if MySQL isn't flushing the error explicitly, any >> message it logs that way may not turn up immediately. >> >> > Other than >> > that I don't think there's anything unique about this case, but I've >> > noticed >> > it happening in other MySQL warning situations as well. >> >> Only other thing I can suggest that this point since it is >> reproducible by you, is to configure with a single daemon process and >> attach GDB to that process and try and capture stack trace for me to >> look at. For how to do that, see: >> >> http://code.google.com/p/modwsgi/wiki/DebuggingTechniques#Debugging_C... >> >> If you can do that, I'll have a think about it and see what else I can >> suggest. >> >> Graham >> >> > ---- >> > David Cramer >> >> > On Wed, Jul 8, 2009 at 8:00 PM, Graham Dumpleton >> > <[email protected]> wrote: >> >> >> 2009/7/9 David Cramer <[email protected]>: >> >> >> > We are running the aptitude package (in Ubuntu) which says "Version: >> >> > 2.3-1build1". As far as the global interpreter goes our config looks >> >> > like this: >> >> >> > WSGIScriptAlias / /home/ibegin/iplatform/handler.wsgi >> >> > WSGIDaemonProcesswww.ibegin.comdisplay-name=ibegin.com >> >> > processes=3 threads=10 stack-size=512kb deadlock-timeo$ >> >> > WSGIProcessGroupwww.ibegin.com >> >> >> > I didn't quite understand in your post if you are suggested to add the >> >> > global flag, or just leave the default. >> >> >> The default is actually: >> >> >> WSGIApplicationGroup %{RESOURCE} >> >> >> This in simple case of 80/443 ports, equates to a named sub >> >> interpreter being used with name composed from: >> >> >> SERVER_NAME|SCRIPT_NAME >> >> >> That is, combination of name of virtual host and the mount point of >> >> the WSGI application. >> >> >> Because it is a named sub interpreter, it is actually a Python sub >> >> interpreter within the same process. >> >> >> So, what I want you to do is override this default and explicitly define: >> >> >> WSGIApplicationGroup %{GLOBAL} >> >> >> The value '%{GLOBAL}' effectively gets internally expanded to be empty >> >> string, ie., '', which in mod_wsgi is used to refer to the main Python >> >> interpreter. That is, the interpreter that was created when >> >> Py_Initialize() was called. >> >> >> The main Python interpreter is special in as much as third party C >> >> extension modules which use simplified GIL state API will only work >> >> properly in Python main interpreter. There are also other things C >> >> extension modules can do which will also cause them not to work in a >> >> Python sub interpreter, but will still work in the Python main >> >> interpreter. >> >> >> In delegating WSGI application to main Python interpreter within the >> >> process, does mean that that should be only WSGI application delegated >> >> to that daemon process group, unless you qualify use of >> >> WSGIApplicationGroup within Directory or Location container to say it >> >> only applies to a specific application delegated to that daemon >> >> process group. >> >> >> Anyway, since it is moderately reproducible, just add: >> >> >> WSGIApplicationGroup %{GLOBAL} >> >> >> and see if you can still trigger it. That will at least answer >> >> question of whether it helps. >> >> >> As I said before, my recollection is that when using GeoDjango that >> >> you need to do this. >> >> >> Graham >> >> >> > If the bug which you are referring to only happens when a request is >> >> > cancelled that wouldn't be our issue. Im personally reproducing these >> >> > in the browser, and it's a full page load which ends up with a default >> >> > Apache ISE page, and a useless message in the error.log (thus the >> >> > reason this is such an issue for us, we're unable to debug anything we >> >> > can't reproduce). >> >> >> > On Jul 8, 7:37 pm, Graham Dumpleton <[email protected]> >> >> > wrote: >> >> >> 2009/7/9 David Cramer <[email protected]>: >> >> >> >> > We're having some issues with the dread seg faults. I've been going >> >> >> > through the checklist and so far I'm not finding anything. >> >> >> >> > It happens in 2 specific areas right now: >> >> >> > - MySQLdb throwing a warning. >> >> >> > - Geodjango throwing an error in it's __del__ (sys.stderr). >> >> >> >> > I believe this may be entirely with __del__'s but I'm not sure how >> >> >> > internals of MySQLdb work. I've confirmed expat and mysqldb are the >> >> >> > same. We had no mysql db module for apache, but I'm guessing that's >> >> >> > not abnormal. I've also confirmed that mod_python is uninstalled so >> >> >> > there should be no conflicts from there. >> >> >> >> > The two specific things we see in apache are: >> >> >> >> > - [Mon Jul 06 10:10:57 2009] [error] [client 207.97.218.238] >> >> >> > Premature >> >> >> > end of script headers: handler.wsgi >> >> >> > - [Mon Jul 06 10:10:57 2009] [notice] child pid 32555 exit signal >> >> >> > Segmentation fault (11) >> >> >> >> Hi David, saw your posts on #django about white 500 pages. Been >> >> >> meaning to drop you an email about it and see what it was about. >> >> >> >> A couple of questions. >> >> >> >> First, which version of mod_wsgi are you using? >> >> >> >> Second, are you using: >> >> >> >> WSGIApplicationGroup %{GLOBAL} >> >> >> >> to ensure that Django running in main interpreter inside of the daemon >> >> >> process you are delegating it to? >> >> >> >> My understanding is that parts of GeoDjango, or things it uses, will >> >> >> not work in Python sub interpreters and so necessary to force it to >> >> >> run in Python main interpreter, which for mod_wsgi is don't use the >> >> >> above WSGIApplicationGroup directive and setting it to '%{GLOBAL}'. >> >> >> >> There is also one known cause of a segmentation fault in daemon mode >> >> >> with current 2.X release tar balls. It only happens in rare >> >> >> circumstances as it is dependent on client closing connection at >> >> >> specific point in between Apache accepting request and WSGI >> >> >> application making first attempt to read request content. The patch >> >> >> for this issue is: >> >> >> >> Index: mod_wsgi.c >> >> >> =================================================================== >> >> >> --- mod_wsgi.c (revision 1351) >> >> >> +++ mod_wsgi.c (revision 1352) >> >> >> @@ -1540,7 +1540,6 @@ >> >> >> >> if (n == -1) { >> >> >> PyErr_SetString(PyExc_IOError, "request data read error"); >> >> >> - Py_DECREF(result); >> >> >> return NULL; >> >> >> } >> >> >> >> In your case you seem to have associated problem with one of those >> >> >> third party packages, so this latter problem may not be cause and may >> >> >> be sub interpreter issue. >> >> >> >> Graham > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "modwsgi" 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/modwsgi?hl=en -~----------~----~----~----~------~----~------~--~---
